Allow configuring if agent can see through walls

[findmyway]

Currently the agent can see through walls by default.

[landrumb]

Should the agent be able to see only in cardinal directions, like an orthogonal projection where perspective lines are all parallel, or with a traditional perspective? I made the following not-to-scale representation of the view to illustrate the difference. Orthogonal perspective would be easier to implement, but the traditional perspective would be more interesting and realistic.

[findmyway]

Good question.

I prefer the latter.
This may be useful to you if you want to make an attempt to implement it:
https://github.com/maximecb/gym-minigrid/pull/98/files

[landrumb]

The occlusion described in that pull request modified a bidirectional orthogonal occlusion to allow corners like the one described in the description to cast shadows more realistic shadows, but that still does not create a system where occlusion can involve angles other than cardinal directions. I have a handful of approaches I'm thinking about to create a system which can incorporate viewing angle, but they all would contribute not-insignificant overhead before some optimizations I have in mind, and more than likely after them.

• using polar coordinates of the corners of opaque objects to describe a region of θ where points with r greater than that of the obstruction are not visible, and generating a mask based on this to adjust the final output. This is currently my favorite idea because it seems interesting to implement and is probably most efficient, although it would depend on the relative speed of asin(), as it (or acos()) would need to be called for every point in the view radius. However, I expect the built-in arcsine approximation is probably far more precise than we would need for such a coarse grid, and a handful of terms of the Maclaurin expansion for arcsine would probably provide more than enough accuracy with very little overhead.
• using a recursive method or iterator to forward ray trace from each point on the perimeter of the view radius to the agent, and hiding points which were not traversed by a ray which reached the agent. This would be relatively straightforward to implement, but seems very inefficient.
• for static environments, pre-baking all the occluded areas for any given location using the recursive/iterator method, and referencing the mask for a given coordinate (x,y) to determine which points should be obstructed. This has the potential to be fast, but could be overkill and would really only be beneficial for environments where one world is used for an extended period of time without changing.

[findmyway]

Hi @landrumb

I have a handful of approaches I'm thinking about to create a system which can incorporate viewing angle, but they all would contribute not-insignificant overhead before some optimizations I have in mind, and more than likely after them.

Awesome! I think non-insignificant overhead is inevitable and acceptable.

We can start from the first approach. The size of the agent's view is usually relatively small. We can compare the efficiency with the second approach. My intuition is that, the second approach doesn't seem to be very inefficient.

The third approach also looks charming. As you said, it may be useful in statical environments. I think we can lazily cache the mask of the agent's view in this case.

[landrumb]

@findmyway I have an implementation working at least close to what I'm looking for, but I'm having a hard time incorporating it into get_agent_view!() because I don't fully understand its arguments and by extension its logic. p::CartesianIndex and dir::LRUD are intuitive, and I'm reasonably confident that v::AbstractArray{Bool,3} and a::AbstractArray{Bool,3} represent the view and grid respectively, but I don't know how to find where there are opaque objects using those arguments.

Obviously, transparency has to be implemented on objects, which I have not done, but it seems like the best way to do transparency may be with an attribute, as certain objects like doors can be conditionally transparent or opaque.

If you'd like to see what I have so far, it's on branch landrumb-issue-30 on my fork, or I can just open a pull request.

[findmyway]

Obviously, transparency has to be implemented on objects, which I have not done, but it seems like the best way to do transparency may be with an attribute, as certain objects like doors can be conditionally transparent or opaque.

Currently the door has only two properties: symbol, color. We can add another field like open or closed as a type parameter just like the color.

get_agent_view_inds will get the indices of the agent's view box from top-left to bottom-right. Then ind_map will rotate the result from get_agent_view to put the agent in the top-middle position.

Then we can get all the opaque objects' mask by changing the get_agent_view! slightly:

GridWorlds.jl/src/grid_world_base.jl

Line 84 in f46e78c

v[:, ind_map(ind.I, view_size, dir)...] .= a[:, inds[ind]]

Here, we need to change the variable v into a 2d Matrix m and add a function is_opaque:

o = findfirst(w[:, inds[ind]])
m[ind_map(ind.I, view_size, dir)...] .= isnothing(o) ? false : is_opaque(w.objects[o])

[findmyway]

Hi @landrumb

Is there anything I can do to help to add this feature? 😃

[landrumb]

@findmyway I was busy yesterday and haven't gotten a chance to sit down and try to incorporate it into get_agent_view(), but I should have time today and/or tomorrow. I think I'll be able to handle it, but I'll let you know if there's anything I need help with.

[landrumb]

@findmyway I've overestimated my ability. How do I get the object at a given index from the Bool arrays passed to get_agent_view? You use w in the code in your comment, but does that mean I need to add the environment as an argument to get_agent_view?

[findmyway]

Yes, and note that WordBase is a subtype of AbstractArray.