Code center > Suggestions

vision - distance discrimination

(1/4) > >>

EricL:
I've got the rest of shape visibility implemented now for 2.43w.  There were two cases missing in pre 2.43w drops:

1) The case where a bot is off the corner of a shape and the eye spans the shape corner.  In this case, the bot eye value registered the shorter of the distances of the interestion points of the two eye edges with the shape sides, not the distance to the corner as it should.  In cases of wide eyes where the eye edges don't even intersect the shape, the eye didn't see it the shape at all!   Now the eye value correctly registers the corner as the closest part of the shape in view and it works for any and all eye widths.

2) The bot is off the side of the shape and the eye spans the closest point of the shape (the point of interestection of the shape edge and line drawn perpendicular to the shape edge through the bot center).  Simialr to above, in cases of wide eyes, the bot may not even see the shape in current drops.  Now the closest point is registerred and everything works for all eye widths.

I have several issues for comment.  Let me try to be breif and precise.

Q1) Are bot eyes located at the bot center or at the edge of the bot (I.e. at it's radius)?  Particularly for bots of large size, this has bearing on absolute eye values, distance discrimination and whether bots can and should see things inside themselves (such as when a vastly smaller bot penetrates it).  Currently, the eye value equation factors in the viewing bot's radius, but in sort or a strange way.   Imagine 2 bots, A and B, each exactly the same distance away from a third bot C.   If A is considerably larger than B, it's eye value when looking at C will be somewhat higher than when B looks at C, soley because it is larger.  The purpose of this (I assume) is to sort of locate eyes on the bot's edge.  But A can still see things within itself and the ultimate highest possible value of one of A's eyes (occurs when it is centerred right on the thing it is viewing) will be larger than B's ultimate highest eye value.   Bascially, being larger conveys slighty better distance discrimination capabilites.  

Q2) Should we increase the range of eye values for better eyesight distance discrimination?  This subject has been discussed before.  Currently we are using only a fraction of the range of values for eyesight, which seems to me like a waste.  If we want to allow for pricision burrowing in shapes or detection of shape imperfections due to previous burrowing or the identification of a small hidden bot moored against the side of a shape using distance alone or precision ambush tactics such as hiding around shape corners or precise dodging of visible shots, we are going to need better eyesight resolution.  I can still make it non-linear, as it is today, but doing so over a larger range of values would open the door I think to more precisie behaviour and interaction with the environment.  I would implement this via a toggle of some sort for backward compatability, either a per-bot settable sysvar or a DNA file flag.   Bots could choose to use the higher range or not.

Numsgil:
Q1: This is an artifact from way before my time.  Originally bot sizes were fixed, and the eye values were presumably decided arbitrarily by Carlo.  When varying bot radii were introduced (this existed before my time too, but I probably exasperated the results when I added realistic volume calculations) the eye values were changed to make bots backwards compatible.

When I first started 2.4, I started messing with eye values to try and make them more self consistent by placing the eye on the edge of the bot.  But it broke most existing bots and was a real sore spot so I changed it back.

Another peculiarity of eyes and large bots: a bot's vision radius doesn't change as it gets larger.  Large bots can't see any further than small bots, but there's less room between them and the edge of their vision radius.

Q2: Don't mess with existing eye return values.  It's just a huge headache for everyone involved, at least in my experience.  An alternative might be to introduce another set of eyes that are more self consistent.

shvarz:
I say please mess with whatever you want, as long as things improve

In my opinion:
- eyes should be located on the periphery of the bot
- eyes should not be able to see inside the bot (back towards center)
- eyes can return either value to center or to periphery, it's not important because bots can estimate their own radius and adjust accordingly. I think it makes more sense to measure the distance from the eye, not from the center.

Also, if you want to give bots control over how far they could see, then I'd suggest balancing it out by introducing a preset "depth of field". Say DOF=50%, then if a bot sets its eye power to 100, then it gets accurate numbers only within 50-150 interval. Anything beyond 150 - it does not see it, anything closer than 50  - it can't tell how close it is, just get info that something is blocking the eye.

EricL:
I'm noddling the comments and will comment on them soon.

On a related issue, 2.43w makes a slight change in .refxpos and .refypos.  These now return the position of the nearest point on the viewed object that is in view of the focus eye.  For a viewed bot, this isn't a huge change, especially for small radii bots.  The refvar position will now be the cloest edge of the viewed bot that is in view asopposed to the bot's center.   I don;t think this will make much difference to omnieye bots or other revpos uses.

For shapes, obviosuly the change is much larger.  It actaully makes these refvars worth something for shapes and allows a bot for example, to chart and remember the dimensions or a specific location of a shape or portion of shape, circle it at a fixed distance, return to or defend a specific den between two shapes, etc.

Numsgil:

--- Quote from: EricL ---On a related issue, 2.43w makes a slight change in .refxpos and .refypos.  These now return the position of the nearest point on the viewed object that is in view of the focus eye.  For a viewed bot, this isn't a huge change, especially for small radii bots.  The refvar position will now be the cloest edge of the viewed bot that is in view asopposed to the bot's center.   I don;t think this will make much difference to omnieye bots or other revpos uses.
--- End quote ---

This might cause some issues.  Have you played around with any bots that use refpos for navigation to see how they behave?  I can maybe see some problems with bots orbiting each other.  Of course, as long as the bots are round the closest point will lie on the segment connecting the bot's center, eye, and target bot's center, so it might just change eye values a little.

Navigation

[0] Message Index

[#] Next page