Hi folks,

Been busy and so, many things have stalled.

We've just had the concrete floors resurfaced - it looks like they've been
ground down to fresh, clean concrete, and are likely to be sealed in the near
future.

I had talked with the VP a while back about painting various lines on the floor,
and I figured we could paint arrows in the direction of the nearest emergency
exit.

So I ran A* on a simple map of the warehouse, and it does OK.
It does take longer than I'd like to scan the image and generate the arrays of
walkable vs non-walkable pixels, and then again to solve the "maze".

The real issue I'd like to solve is that A* didn't care that the shortest path
involved exiting the building and then coming back in.  That likely violates
policy, and plus the doors are exit-only (panic bar on the inside only).

At present, I'm just using image pixel color to define where empty space or a
door is, and everything else is solid object.  (the SDL currently draws over
anything it determines as solid - regardless of the color on the map -  with a
bright green, as a means evaluating the quality of the image colors & evaluation
logic)
Also, as you can see, the color logic is cumbersome and finicky - dark red
pallets get evaluated as "doors" (walkable space) and very dark grey doesn't
register as solid (because my logic sucks that bad)

#if (((PixelColor.red + PixelColor.green + PixelColor.blue)/3 < 0.9) &
(PixelColor.red < 0.85 & (PixelColor.green + PixelColor.blue)/2 > 0.05))

#declare walkability [X][Y] = unwalkable;

I'd like:
1. A clear manner of coding a door as being one-way.  Keep in mind that the door
in the graphic may be many pixels wide/deep, and there's no color
differentiation between inside and outside.

2. I'd like a general solution, but also one that minimizes the amount of
additional work to be done before running the pathfinding from the start point
to the destination (designated meeting place)

3. Any ideas on how to minimize the search time, even though they might cost
more initial work are welcome.  The idea is to run simulations when there may be
obstacles blocking the typical posted primary fire exit path.

I've been thinking of color coding, specifying a door <x, y> coupled with a
directional vector (I currently have 22 doors), using Crossing Numbers, Voronoi,
etc.

Also of interest is finding fire extinguishers, first aid kits, and AED
defibrillators.

With regard to fire extinguishers, I asked the question: what if I need one, but
someone has already taken it?  What direction do I go to get the next closest
one?  Or the third?

I'd welcome any ideas, or even questions that help me avoid future unseen
pitfalls.

- BW

Post a reply to this message

Attachments:
Download 'a-star floorplan exits.png' (403 KB)

Preview of image 'a-star floorplan exits.png'

"Bald Eagle" <cre### [at] netscapenet> wrote:

>
> So I ran A* on a simple map of the warehouse, and it does OK.
> It does take longer than I'd like to scan the image and generate the arrays of
> walkable vs non-walkable pixels, and then again to solve the "maze".
>

The print factory where I worked (solvent based rotogravure printing) was
sectioned. Huge safety doors would close of sections in case of emergency.
People would try to outrun the closing of these doors, the building is 250 m
long with 5 sections. Not a situation you want.

To get proper routes out we added more outside gathering points for
people(counting). Maybe adding an extra gathering point (green dot?) on the
other side of the building works?


ingo

Post a reply to this message

"ingo" <nomail@nomail> wrote:

> The print factory where I worked (solvent based rotogravure printing) was
> sectioned. Huge safety doors would close of sections in case of emergency.
> People would try to outrun the closing of these doors, the building is 250 m
> long with 5 sections. Not a situation you want.

Jeez.  Sounds like that scene from Moonraker.

> To get proper routes out we added more outside gathering points for
> people(counting). Maybe adding an extra gathering point (green dot?) on the
> other side of the building works?

I was just trying to make the solver take as long and convoluted path as I
could, and the algorithm that I have now only takes a start and target point as
input.
I think I can sequentially solve for different paths and store those in
different path number array, but at the present time, that's about it.

I was just trying to conceptually figure out how to code a 1-way door

After that, I figured some thing to try might be:
  solve a single designated path
  solve multiple single paths
  solve a progressive path with sequential destination points
  solve a single path then repeat using a given obstacle
  find the closest destination of many to a given starting point

But mostly I was just thinking that I might have to use different versions of
the map, or someone might want me to test this on another site, and I wanted to
minimize the amount of work I might need to do to start having the algorithm do
its thing.

I tried loading yesbird's povlab website to see if I could use that to speed up
the parsing, but it's in a "forbidden country"   <eyeroll>

- BE

Post a reply to this message

On 21/04/2024 15:43, Bald Eagle wrote:
> I tried loading yesbird's povlab website to see if I could use that to speed up
> the parsing, but it's in a "forbidden country"   <eyeroll>

Yes, guys, sad, but true. Last two years I'm living in "forbidden
country", trying to suppress this unpleasant fact. But "open source" is
always open and free, so if you have hardware resources, you can use my
code to make the same service in any "unforbidden" country:
https://github.com/syanenko/povlab.online
--
YB

Post a reply to this message

On 21/04/2024 15:43, Bald Eagle wrote:
> I tried loading yesbird's povlab website to see if I could use that to speed up
> the parsing, but it's in a "forbidden country"   <eyeroll>

... or try VPN.

Post a reply to this message