Alternative View, Luminosity, And Distance Calculations

Page: 1 2 3
ID:115209
 
Jun 29 2011, 7:56 pm (Edited on Jun 30 2011, 9:27 am)
Applies to:DM Language
Status: Open
Issue hasn't been assigned a status value.
As I've read through the features tracker, I've read many in which it's stated that there are multiple methods of implementation and they are put on hold until that's figured out. In the case of these, range(), orange(), get_dist(), view(), oview(), and luminosity, one method was chosen, and it was the simplest method at that. I request that these functions be augmented to include varying distance calculations and that get_sight() be added as a get_dist() counterpart.

The new format for distances and views could work in the same manner as Blend().
range(center, Dist, CHEBYSHEV)
orange(center, Dist, CHEBYSHEV)
get_dist(Loc1, Loc2, CHEBYSHEV)
Arguments could be CHEBYSHEV, MANHATTAN, SHIFTED, and EUCLIDEAN, as detailed here. Maybe even a little help from table look-ups if necessary?

Here is how get_sight() could look. 
get_sight(Loc1, Loc2, SIMPLE)
Arguments could be SIMPLE, DIGITAL, and BRESENHAM, as detailed here. Or, it could be hooked into how the field-of-vision is calculated, as shown below.

And view() would have two arguments, one for the distance calculation and one for the field of vision calculation. 
view(center, Dist, CHEBYSHEV, DEFUALT)
oview(center, Dist, CHEBYSHEV, DEFAULT)
Arguments could include DEFAULT (as I have no idea of the algorithm), BUCKET, MUTUAL, PERMISSIVE, RAYTRACING, et cetera.

The world should have a field_of_vision variable to determine how opacity and luminosity is handled on the map. Alternatively, this variable could just override or replace the extra variable in the view() and oview() functions.

P.S. Doubly awesome if you threw in three-dimensional versions of each of the functions, just for good measure.

If there is anything I'm missing and you'd like me to brainstorm, let me know so I can update the request.
Jul 3 2011, 12:33 pm
Upvoted.
Jul 3 2011, 12:44 pm
Same.
Sep 7 2011, 12:35 pm
Bumping for remembrance.
Sep 24 2011, 7:48 pm
This would be amazing, although I'd suggest making the third param optional, so as to maintain compatibility with current DM code.
Oct 5 2011, 5:28 am
Could you explain how you would use these?
Oct 5 2011, 7:47 pm
Toadfish wrote:
Could you explain how you would use these?

Let's say you want to make a lighting system for a game that makes a circular field of light around you. With the normal distance calculations, it comes out looking like a series of squares. With alternate distance calculations you'd be able to get distance in several different ways, allowing for more accurate distance calculations to those who would use them.

Another example would be an AoE attack, if it's a circular attack then you'd have to code out the distance calculations yourself, and even then it would be much less efficient than a built in procedure.

It mostly has to do with those who want to make a lighting system, since there's much more processing involved in doing so.
Oct 24 2011, 6:30 pm (Edited on Oct 26 2011, 12:11 pm)
Bravo: I am not familiar with lighting algorithms but I see no reason why an euclidean circle should not be calculated through euclidean distance. Can you give me an explicit example where using a distance formula under a different metric space explicitly assists you in creating a better 'circular field of light'?

Because everything mentioned in this request can be softly implemented without too any trouble, the two reasons to have this built-in is efficiency, and convenience. This is why I'm interested in seeing obvious applications before deciding whether to upvote.
Oct 24 2011, 7:32 pm
it's not hard to implement something in soft code, you are correct, however we can use pixel movement as an example that, even though soft code can work, the built in version will always be more efficient.
I believe that'd what HTDK was getting at, because when it comes to lighting systems, you're going to be doing thousands of calculations every second. Having them built in would actually make a difference in speed. Though I think a better option for this would to be the inclusion of a built in lighting system, though I'm not sure that would work very well. It all depends.
Oct 26 2011, 12:12 pm
I'm sorry, but you haven't answered my question, you've only repeated what I just said. Can you give me practical examples where this feature comes in handy? I don't understand, for example, what Manhattan distance has to do with dynamic lighting. I want to see practical uses of this feature so I can decide whether to upvote it or not.
Oct 26 2011, 12:32 pm
Different calculations can result in different distances.

http://www.byond.com/members/jtgibson/forum?id=12

This is a library that will calculate the distance for you, however when it comes to the procedures many of them use sqrt() which is a very slow proc because the math behind it is very dodgy. In single or multiple use, it runs fine, but when it's calling hundreds of times per tick in order to get distance values for lighting, it can bog down a server immensely. It's not just because of sqrt() though as many people ca easily point out, however it would be extremely beneficial if these calculations were included in get_dist() as built in code so that not only can you get different distances but you can also get them much faster than when using this library.

So, basically speaking, depending on the math you use you're going t get a different result, and in most cases the distance calculation that byond uses by default isn't what people what to use.

Practical example can be codi9ng for lighting systems, AOE attacks or spell effects in games, or even for calculating distance for something like Oasiscircles 3d Demo.
Oct 26 2011, 1:13 pm
To put it simply, these alternate calculations create actual circles, instead of the squares that BYOND currently does.
They also give more specific/accurate distance values at angles, instead of just the difference in x/y coordinates.
Oct 26 2011, 1:20 pm
To be fair, one of the functions returns right angled rhombi.
Oct 26 2011, 4:22 pm
What does 'creating actual circles' mean? The only thing that comes to mind is that if in the algorithm:

proc/circle(turf/source, radius=3)
  var/list/l = new
  for (var/turf/t in range(source, 5))
    if (get_dist(t, source) == 3))
      l += t
  return l


You replace get_dist(t, source) with something like get_dist(t, source, MANHATTAN), the result will look smoother. If this is true it's rather unintuitive because mathematically speaking Manhattan distance should result in a diamond shape.

If you want to create actual circles you need to adjust this algorithm for a discrete map, which has little to do with changing the metric.
Oct 26 2011, 4:28 pm
This is true, but Manhattan isn't the only choice there. And that could be used as a stylistic choice. If I were playing in an isometric world, I would much rather my distance be calculated in Manhattan than Chebyshev.

Either way, sight is the more important calculation. There is almost no quick method for soft-code line of sight, and no decent method otherwise.

Personally, I like the way shifted distance looks. That would be my preferred method for lighting.
Oct 26 2011, 4:29 pm
Toadfish wrote:
What does 'creating actual circles' mean? The only thing that comes to mind is that if in the algorithm:
> proc/circle(turf/source, radius=3)
>   var/list/l = new
>   for (var/turf/t in range(source, 5))
>     if (get_dist(t, source) == 3))
>       l += t
>   return l
>

No, not an Outlined Square. A Circle. Also, your proc is looping through a range of 5, and then comparing to a distance of 3, when it takes a radius parameter that should replace both of those numbers...
Oct 26 2011, 4:34 pm
Basically none of these metrics would give me a better circle, Hiro. Euclidean seems to me like the only applicable metric here.

Changes to line of sight calculations sound interesting but I could not find a relevant graphical comparison of the four methods in the links you provided. Before up-voting, I would like to see whether there is a significant difference.
Oct 26 2011, 4:36 pm
Falacy wrote:
Toadfish wrote:
What does 'creating actual circles' mean? The only thing that comes to mind is that if in the algorithm:
> > proc/circle(turf/source, radius=3)
> >   var/list/l = new
> >   for (var/turf/t in range(source, 5))
> >     if (get_dist(t, source) == 3))
> >       l += t
> >   return l
> >

No, not an Outlined Square. A Circle.

Do you know what the definition of a circle is? It is the set of all points equidistant from the centre.

Also, your proc is looping through a range of 5, and then comparing to a distance of 3, when it takes a radius parameter that should replace both of those numbers...

Yes, so pretend 'radius' is written where there instead of the 3,5.
Oct 26 2011, 4:38 pm
It's not really about creating a circle, it's about alternative calculations. I will post some pictures later of each of these within a lighting system so that you can see the differences.
Oct 26 2011, 4:39 pm
Thank you, yours are the only relevant answers here.
Page: 1 2 3