We have detected that cookies are not enabled on your browser. Please enable cookies to ensure the proper experience.
Page 1 of 2 1 2 LastLast
Results 1 to 25 of 36
  1. #1
    Join Date
    Jun 2011
    Location
    Leeds
    Posts
    5

    AoE Squares - Ugly and Weird

    Hello,

    I don't post on the forums very often, but this is something which just doesn't sit well with me. I can't see any similar threads on this topic, so I thought I would start one.

    So with the latest update we received squares around AoE, and my initial thoughts were that this would be useful. However my experience in game has been mixed.

    (1) Horrah - now we can see where we can stand!
    (2) Red = bad, white = good, yes I can cope with that :-)
    (3) But wait, now there are squares everywhere, and visually it looks like some kind of LotRo/Matrix mash up.
    (4) I'm impressed by barrow-crawlers which drop perfectly square pools of acid, plus it now looks like laser quest in the barrows.
    (5) Those catapults in BfE do a great job of creating impact craters that are not only perfectly square, but also line up perfectly with the stones on the floor.

    I guess what I am saying is that instead of adding a square around a circle, which represented a square (!) why not just make the effect circular? It would make much more sense (round pools of acid, imagine!) and retain the aesthetic of the game, and not over-complicate the screen.

    And before anyone tells me, I know we can turn it off (if you realise that you are looking for the option "enable persistent area effect visualization" - I mean honestly, "turn off those damn squares" would be clearer) but then I would have less information about the battle compared to everyone else.

    Discuss!

  2. #2
    You could just turn it off.

    Oops, guess you already saw that.
    Lenghad - Champion on Arkenstone (Main char)

  3. #3
    it's a square because it is less cpu intensive to figure out if something is in a square than a circle. if anything they'd get rid of the circles, but i like em

  4. #4
    It takes considerably less computing cycles to calculate if something is inside or outside of a rectangle then it does a circle. Changing that detection code to use circles would add more burden on the servers (which might add more lag). It's worked this way since Lotro launched -- the only difference now is the graphic element added to avoid confusion.

  5. #5
    Join Date
    Jun 2011
    Location
    Leeds
    Posts
    5
    I appreciate there are probably technical reasons for effects being squares rather than circles, but actually drawing squares around the effect does seem to highlight how inadequate the technology is!

    Maybe if the circles were actually the same size as the effect (most of the time, the squares are must larger than the circles inside them) then the visual squares wouldn't be necessary? As it stands I just see it as a bit of a clobbered together solution to a rather silly problem.

  6. #6
    Join Date
    Jun 2009
    Location
    at the keyboard
    Posts
    1,744
    well they do seem a bit lame imho on the other hand I appreciate the low tech approach, so to speak, because it's less lag for my machine, even if the niftier, shinier effects (like in other games) have a greater "cool" factor. So I'd rather have it than not, myself. I dunno exactly where the boundaries of effects are, according to the actual game, not just my subjective estimates, so I'd rather not comment on the whole circle vs square.
    [center][color=teal]Wingwoz (on hunters in LOTRO), "I prefer to think of them more like Elvis or James Dean. Terminally self indulgent but their presence in a party, nay, the very fact that they ever existed, makes the world a cooler place."[/color]
    [color=orange]'[i]Zairente hums, "Little rabbit Poo-kie / running through the Di-res / scooping up the Mon-archs / and BANGING 'em on the head."[/i]'
    [i][url=http://my.lotro.com/user-984907/]The Antics and Ramblings of Family Nenaelin[/url][/i][/color][/center]

  7. #7
    Join Date
    Jun 2008
    Posts
    4,405
    I got stunned by a catapult rock while standing outside of the impact square last night. Perhaps I need a smaller square around my character so I can see how much space I'm actually taking up beyond that of my visible physical proportions.

  8. #8
    Testing if something is inside a circle is actually less CPU intensive.

    A point in circle test is comparing a character position minus circle position to the radius of the circle. Whilst a point in rect test is comparing a character position to 4 lines i.e each side of the rect. That's often a reason for choosing bounding sphere tests vs bounding box when you can get away with one vs the other. Sphere/Sphere intersection tests are a lot faster than Box/Box intersection tests.

    Unfortunately, spheres don't often fit a character shape as well as a box or capsule does.

    Regardless of that, I also think the current implementation looks out of place.
    Last edited by Achlys; Mar 12 2013 at 07:14 PM.

  9. #9
    Join Date
    Jun 2011
    Location
    Leeds
    Posts
    5
    I think Lestache raises a good point - what are the boundaries of our characters? Must be a square around our feet - I've also had that catapult situation.

    And that's interesting about spheres/circles actually being less cpu intensive than squares. Always learning :-)

  10. #10
    Quote Originally Posted by Achlys View Post
    Testing if something is inside a circle is actually less CPU intensive.

    A point in circle test is comparing a character position minus circle position to the radius of the circle. Whilst a point in rect test is comparing a character position to 4 lines i.e each side of the rect. That's often a reason for choosing bounding sphere tests vs bounding box when you can get away with one vs the other. Sphere/Sphere intersection tests are a lot faster than Box/Box intersection tests.
    Shouldn't it be two compares? Circle testing is (dx)^2 + (dy)^2 < (r1 + r2)^2, while square testing is |dx| < (s1 + s2) / 2 && |dy| < (s1 + s2) / 2.

    I'm not actually sure which one's faster (2 fmuls, 1 fadd, 1 fcmp versus 2 fabs and 2 fcmps) - but square testing does have the advantage of letting you branch early, so you can skip a couple of the operations. Of course, you're supposed to be avoiding conditional branches, so that might not work out so well.

  11. #11
    Point in circle test would be:

    (b.x - a.x)² + (b.y - a.y)² <= (a.r + b.r)²

    Sphere/sphere testing is only slightly different:

    (b.x - a.x)² + (b.y - a.y)² + (b.z - a.z)² <= (a.r + b.r)²

    However for the rect or bounding box case, it depends if you're using axis aligned or object oriented shapes.

    For axis aligned bb you'd have no intersection if (ignore Z for rect/rect):

    a.min.x > b.max.x || a.max.x < b.min.x || a.min.y > b.max.y || a.max.y < b.min.y ||
    a.min.z > b.max.z || a.max.z < b.min.z

    That's four or six tests to determine an intersection, although early out cases can reduce that to 1-6 tests if there's no intersection. However, there's also a need to work out the min and max x/y/z coords for this test. Chances are the AABB stores these values so they're a quick lookup however, testing isn't the only concern.

    You're having to keep recalculating your AABB (the min/max values above) whenever your object rotates, even though the actual intersection test is trivial, there's overhead in working out the new AABB for the shapes new orientation. If you want to avoid this maintenance then you've to use object oriented bounding boxes, but these are much more involved for doing intersection testing.

    Main point is, circle/circle or sphere/sphere is going to be faster as they suffer non of the BB issues when rotation is taken into account. However, it may not be practical as a box can be a better fit for humanoid shapes. I can't off hand remember if a sphere/box test would provide optimisation opportunities making it more efficient than an OOBB/OOBB test though and it's a little too late for me to go digging through my notes to find out.

    Edit: As a better explanation than I have probably given, have a look here. I probably should have googled an example before trying to explain it to begin with

    Edit2: Just a quick note that whilst sphere/sphere may involve fewer calculations, chances are high that AABB's are already been calculated and used for other parts of collision detection in the game, such as character/world collisions. If the AABB is already calculated there's not a whole lot more overhead in doing an AABB/AABB test for AOE. Although it's equally possible the test doesn't need to be too accurate and a simple character pos/sphere test would do to find out if you're a) within the AOE and b) how far inside you are to scale the damage by. No idea which/how the devs are doing it though and there may be other things they've had to take into account that made one option better than the other.

    PS it's getting late, so please excuse any mistakes in typing the above and apologies if it took the thread off topic, to bring it back on, the effect does look out of place compared to all the other effects in the game although some kind of indication is quite handy when the effect of an AOE isn't at least as big as the real damage area.
    Last edited by Achlys; Mar 12 2013 at 08:53 PM.

  12. #12
    Uhm do you guys have any idea how many CPU cycles an average line-of-sight check needs? Or path finding of mobs?
    If the devs are concerned that circle checks for AoE effects might need more cycles then AABB checks, they are clearly optimizing at the wrong end, I'm pretty darn sure about that...

  13. #13
    The engine uses squares to apply the effects, you can disable the outlines if you don't want to see them. In some scenarios it is extremely helpful to see exactly where the boundaries of an effect are, in others it is an eyesore.

  14. #14
    Quote Originally Posted by Lynx3d View Post
    Uhm do you guys have any idea how many CPU cycles an average line-of-sight check needs? Or path finding of mobs?
    If the devs are concerned that circle checks for AoE effects might need more cycles then AABB checks, they are clearly optimizing at the wrong end, I'm pretty darn sure about that...
    Usually efficiency is taken into account with any change made to an engine regardless of how much time other parts are consuming. Not talking about micro optimisations or premature optimisation, but in the sense of, is there a way to do this that's faster and won't take any more effort to implement I.e avoiding premature pesimisation. When it comes to real optimisation, then sure, you go after the part of the engine that shows up as the biggest hit in profiling.

    That said, who knows why the visual indication is a rect, in fact for all we know it's a purely asthetic choice and the underlying aoe calcs might be using distance/radius calcs for damage (the skills do afterall state a radius for the aoe) after a broad phase AABB test returns a set of potential objects within the aoe.

    Regardless of the reasons for it been a rect though, the above posts that mentioned circle tests as less efficient than rect, were IMO inaccurate.

  15. #15
    Quote Originally Posted by Achlys View Post
    Point in circle test would be:

    (b.x - a.x)² + (b.y - a.y)² <= (a.r + b.r)²

    Sphere/sphere testing is only slightly different:

    (b.x - a.x)² + (b.y - a.y)² + (b.z - a.z)² <= (a.r + b.r)²

    However for the rect or bounding box case, it depends if you're using axis aligned or object oriented shapes.

    For axis aligned bb you'd have no intersection if (ignore Z for rect/rect):

    a.min.x > b.max.x || a.max.x < b.min.x || a.min.y > b.max.y || a.max.y < b.min.y ||
    a.min.z > b.max.z || a.max.z < b.min.z

    That's four or six tests to determine an intersection, although early out cases can reduce that to 1-6 tests if there's no intersection. However, there's also a need to work out the min and max x/y/z coords for this test. Chances are the AABB stores these values so they're a quick lookup however, testing isn't the only concern.

    You're having to keep recalculating your AABB (the min/max values above) whenever your object rotates, even though the actual intersection test is trivial, there's overhead in working out the new AABB for the shapes new orientation. If you want to avoid this maintenance then you've to use object oriented bounding boxes, but these are much more involved for doing intersection testing.

    Main point is, circle/circle or sphere/sphere is going to be faster as they suffer non of the BB issues when rotation is taken into account. However, it may not be practical as a box can be a better fit for humanoid shapes. I can't off hand remember if a sphere/box test would provide optimisation opportunities making it more efficient than an OOBB/OOBB test though and it's a little too late for me to go digging through my notes to find out.

    Edit: As a better explanation than I have probably given, have a look here. I probably should have googled an example before trying to explain it to begin with

    Edit2: Just a quick note that whilst sphere/sphere may involve fewer calculations, chances are high that AABB's are already been calculated and used for other parts of collision detection in the game, such as character/world collisions. If the AABB is already calculated there's not a whole lot more overhead in doing an AABB/AABB test for AOE. Although it's equally possible the test doesn't need to be too accurate and a simple character pos/sphere test would do to find out if you're a) within the AOE and b) how far inside you are to scale the damage by. No idea which/how the devs are doing it though and there may be other things they've had to take into account that made one option better than the other.

    PS it's getting late, so please excuse any mistakes in typing the above and apologies if it took the thread off topic, to bring it back on, the effect does look out of place compared to all the other effects in the game although some kind of indication is quite handy when the effect of an AOE isn't at least as big as the real damage area.
    Sorry, why are you calculating AABBs? There's no rotation.

    The reason you use six comparisons for an AABB is given an arbitrary rotation, unless your figure has certain guarentees (and I'm not even sure what those guarantees should be - symmetry isn't nearly enough), the distance to each face of the bounding box from the center point of the object (or really, the point around which you're rotating the object) may not be the same as the distance to the opposite face.

    This should not be the case in for LotRO hotspots. A LotRO hotspot, is, as far as I can tell, defined solely by its width, height, and the x,y coordinates of the center of the hot spot. Actually, I'm beginning to suspect that they're all squares, and its actually defined by its side length and the x,y, coordinates of the center of the hot spot. Once you know the centers of the two objects, all you need to know is the delta-x and the delta-y. And then you just determine whether or not the delta-xs and the delta-ys are small enough, given the side lengths of the two objects.

    Edit: Sorry to continue this, but it really sounds like you're proposing to solve a very complex problem in order to do something very simple.

    Further edit: Okay, given a guarantee that for any point (x,y,z), there exist points (-x,y,z), (x,-y,z), (-x,-y,z), (x,y,-z), (-x,y,-z), (x,-y,-z), and (-x,-y,-z), I think you can avoid calculating the full bounding box, and limit yourself to three comparisons, but that's a pretty strong symmetry guarantee that I'm not it's in anyway realistic to assume that it'll occur.
    Last edited by moebius92; Mar 12 2013 at 10:15 PM.

  16. #16
    Join Date
    Apr 2007
    Location
    Gallifrey. I need a Jelly Baby.
    Posts
    18,103
    Quote Originally Posted by Tamrial View Post

    And before anyone tells me, I know we can turn it off (if you realise that you are looking for the option "enable persistent area effect visualization" - I mean honestly, "turn off those damn squares" would be clearer) but then I would have less information about the battle compared to everyone else.

    Discuss!

    OMG no joke! If it wasn't for the fact that I read the forums, I would have never seen this. I saw the link in the log in screen and saw it from there.
    Life is not a journey to the grave with the intention of arriving safely in a well preserved body, but rather to skid in broadside, totally worn out & proclaiming "WOW, what a ride!"
    Continuing the never ending battle to keep Lobelia Sackville-Baggins in check

  17. #17
    Quote Originally Posted by moebius92 View Post
    Sorry, why are you calculating AABBs? &There's no rotation.
    The aoe doesn't rotate so it'd be a one off calculation, but the players do as they move around within/outside it. That said, the AABB for players would still need calculating regardless of aoe because they'll be used elsewhere in the engine for broad phase collision detection.

    The reason you use six comparisons for an AABB is given an arbitrary rotation, unless your figure has certain guarentees (and I'm not even sure what those guarentees should be - symmetry isn't nearly enough), the distance to each face of the bounding box from the center point of the object (or really, the point around which you're rotating the object) may not be the same as the distance to the opposite face.
    The rotation doesn't matter for the actual comparison, since the boxes are axis aligned. It only comes into play when you needed to originally calculate the AABB for an object, which as you point out would be a one off for a static aoe.

    Even if neither object ever rotated though and the AABB never needed recalculating, there's still a need to perform 1-6 tests to determine if two aabb's intersect.

    Edit: Sorry to continue this, but it really sounds like you're proposing to solve a very complex problem in order to do something very simple.
    The only thing I was stating is that as far as the 3rd and 4th posters comments about the two types of tests, sphere/sphere tests are faster than box/box. I wasn't suggesting turbine had used one or the other or indeed that they havent used a more optimal solution based on the specifics at hand which led to the rect usage. I've no knowledge of their engine or the factors that went into that decision, but to say circle/circle was slower than rect/rect I feel is incorrect. I may not be explaining that well or we both may be talking at cross purposes.

    However as additional references to the AABB/AABB vs sphere/sphere part though http://www.realtimerendering.com/intersections.html And the wikipedia entry touches on it too.

    I have a feeling we're talking at crossed points though and probably risking derailing this thread. If you'd like though we can continue it in a pm?
    Last edited by Achlys; Mar 12 2013 at 11:03 PM.

  18. #18
    Quote Originally Posted by Tamrial View Post
    ...
    (5) Those catapults in BfE do a great job of creating impact craters that are not only perfectly square, but also line up perfectly with the stones on the floor. ...
    Thats a gameplay feature. While T1 is easy, the more complications (banners) you add to that raid, the more important is correct positioning of the trolls. You want to position them in a way, that both tank and dps can move out of catapults with limited interruption.

    Its similar to the ring of Lightning, where you had to carefull position the whole fight in order to maximize PS an reaction time.

  19. #19
    Join Date
    Jun 2011
    Location
    Switzerland
    Posts
    149
    Interesting programming and maths reading guys -

    But why is there squares around camps as well now that as far as I can see you can't turn off - unless someone has the solution.

    To be honest, square or circle, I find this new "feature" to be very ugly and ruins the RP look and feel.

  20. #20
    Join Date
    Jun 2011
    Location
    South Tyrol, sadly in Italy
    Posts
    4,242
    Quote Originally Posted by Tamrial View Post
    I guess what I am saying is that instead of adding a square around a circle, which represented a square (!) why not just make the effect circular? It would make much more sense (round pools of acid, imagine!) and retain the aesthetic of the game, and not over-complicate the screen.
    So instead of adjusting the graphical effect to display the real dimension of effects you think it's better to change how the game works.

    Circles are nice, but they require more calculations then squares. The game uses squares, because they are faster.

    No square was "added around a circle", the circle was put in the middle of the square. You just didn't see the square before the update.

    The game uses squares for 5 years now. Only now that they are displayed you get the idea to change the basic game mechanics? Maybe we should just remove the optical effect, get back to play the game the way it was 3 weeks ago and keep wondering why we get the effects even if we are not in the effect area.

    Circular effects? Sure, why not, but could you not have suggested this 5 years ago?

  21. #21
    Join Date
    May 2011
    Location
    Middle-earth
    Posts
    1,839
    Quote Originally Posted by Prof-Moriarty View Post
    Interesting programming and maths reading guys -

    But why is there squares around camps as well now that as far as I can see you can't turn off - unless someone has the solution.

    To be honest, square or circle, I find this new "feature" to be very ugly and ruins the RP look and feel.
    The camps have a beneficial Area of Effect effect, which is by default visualized since U10.

    You can turn it off by disabling the option "enable persistent area effect visualization". Which I didn't know as well before reading this thread.

    I'm torn. I like the info in battles in instances, but I abhor the squares in landscape, around camps ets.

    I'd like the one option "enable persistent area effect visualization" to be split into - for instances/skirmishes and - for landscape. I guess.

  22. #22

    Circle of squares?

    Nothing to see here...

  23. #23
    Quote Originally Posted by Tamrial View Post
    I know we can turn it off (if you realise that you are looking for the option "enable persistent area effect visualization" - I mean honestly, "turn off those damn squares" would be clearer) but then I would have less information about the battle compared to everyone else.

    Discuss!
    I have looked and looked; can't find the toggle. I even used the "Search" function within Options > UI, nothing for the term "area".

  24. #24
    Join Date
    Oct 2010
    Posts
    243
    Quote Originally Posted by StinkyGreene View Post
    I have looked and looked; can't find the toggle. I even used the "Search" function within Options > UI, nothing for the term "area".
    Under Combat Options, scroll down to the very bottom. It's the last item under 'General Combat', and it's right above 'Mounted Combat'.

    Also, when you search for an option, if there's nothing matching that on the tab you're currently on, you won't see anything. HOWEVER, if it matches something in another tab, that tab will be lit up and the other tabs greyed out. Click on that tab, and you'll see it. Easy to miss, but might help you/others in the future.

  25. #25
    Join Date
    Jun 2011
    Location
    Hertfordshire, UK
    Posts
    2,095
    I think it looks horrible too. I will be turning it off as soon as i can get logged in when i get home, now that i know that i can turn it off that is.
    [I][URL="http://www.swgrp.co.uk/main/socks/"]Wet Socks & Two Smoking Hobits: the mad ramblings of Handee Pokits[/URL][/I]

 

 
Page 1 of 2 1 2 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

This form's session has expired. You need to reload the page.

Reload