Find polygon center coordinates?

  • Here's a working example with which you can play. The key action is compute_hotspot_centroid which takes three arguments: a variable name to return the ath value, a variable name to return the atv value and the name (or index) of the hotspot for which to find the centroid. If the hotspot is not a polygonal hotspot, then the ath and atv values are returned. If however, the hotspot is polygonal, then the center of mass is computed for the polygon (assuming uniform surface density) and the centroid is returned via the first two arguments.

    You math whizzes out there will note that the calculation is very slightly off because this algorithm assumes the polygon is flat, rather than the curved surface that is actually used by krpano. Ahh well, at least it's a much better approximation than averaging all the points! *g*

    Note that this algorithm assumes that the polygon is not self intersecting!

    In this example, there is a button at the bottom of the screen. Pressing it fires off the process_hotspots action, which computes the centroid for each hotspot and then overlays an animated hotspot at this location.

    hope this helps!
    edit--Note, this code has a serious bug in it which was remedied in this post


    This code was edited on May 6th to better handle zero area polygons--in this case the average of the points is used

    5 Mal editiert, zuletzt von pinsane (19. Mai 2010 um 08:55)

  • Hi Steve,

    What do you give your brain to get codes like this one *thumbsup* ?
    I near understand the foreach action but the maths stuff are out of my understanding *wacko* !!!
    It is impressive... and it seems working ...

    But there is some cases that does not work as is expected ...(sorry *whistling* *wink* )

    Considers those following hotspot:

    I would like to know how to solve the issue instead of just to notice it, but I simple do not have the knowledge *tongue* ...
    Perhaps you can... *thumbsup*

    SAlut.


  • What do you give your brain to get codes like this one *thumbsup* ?


    BEER


    But there is some cases that does not work as is expected ...(sorry *whistling* *wink* )
    ....

    I would like to know how to solve the issue instead of just to notice it.
    Perhaps you can... *thumbsup*


    It would seem perhaps that I had too much beer, as I published some code with a pretty serious bug in it. I hang my head in shame... *cry*

    Thanks for finding this Michel. The error in the code is that it doesn't properly normalize coordinates, and didn't account for the 360 degree wrap properly. Here's the fixed code:.

    Unfortunately there's still a problem with this which I'll discuss in my next post (due to the character limit imposed by the forum software).

    steve

    Einmal editiert, zuletzt von pinsane (19. Mai 2010 um 08:59)


  • Unfortunately there's still a problem with this which I'll discuss in my next post (due to the character limit imposed by the forum software).

    To avoid further embarassment, I generated a number of test polygons and wrote some code that would translate each shape onto each of the 6 cube faces to make sure there were no wrap problems. Unfortunately, in doing this I discovered a more serious problem. If you look at the hotspot at the zenith of the above example you'll see that this algorithm still misses the mark. I realized that the approximation I was using, which assumes that I could cheat and treat spherical coordinates as an approximation of cartesian coordinates, fails when the range of either ath or atv in the polygon gets too large. Since we don't have trigonometric functions available in the krpano language (except through javascript), I started trying to use spheretoscreen to do the mapping. Then it hit me. There's a much easier way to do this! Just use Klaus' built-in looktohotspot function and then grab the hlookat and vlookat values:

    It looks like Klaus uses point averaging rather than center of gravity for the lookto function, you can see this by looking at the green shape. The center of gravity method finds a more pleasing center point. That being said, this new method has the merit of working even for geometries at the zenith and nadir.

    Thanks for finding the bug Michel. *thumbup*

    steve

    Einmal editiert, zuletzt von pinsane (19. Mai 2010 um 16:55)


  • It looks like Klaus uses point averaging rather than center of gravity for the lookto function, you can see this by looking at the green shape. The center of gravity method finds a more pleasing center point. That being said, this new method has the merit of working even for geometries at the zenith and nadir.
    steve

    Okay, here's a version that finds the center point using the center of gravity for polygons that span less than 90 degrees, and uses the looktohotspot method for the problematic polygons.

    Thanks again to Michel for pointing out that there was a problem in my first example.

    steve

  • Hi Steve,

    Zitat

    It would seem perhaps that I had too much beer, ...

    perhaps *squint*

    Zitat

    ...as I published some code with a pretty serious bug in it.

    not so serious *wink*

    Zitat

    .... I hang my head in shame... *cry*

    Please, do not *g* !!! It would be a big loss, you are a MEGACRACK using the krpano features in trying to find solutions to complex problems *thumbsup* .

    For example, it is amazing to see how you use the delayedcall to execute the cmd string variable... *thumbup*
    or the use you do of the looktohotspot() in combination with the freezeview(true) to avoid the view change ... *thumbup*
    your foreach function... *thumbup*

    I think we are lucky to have your contributions on this forum ... I am lucky *smile* !!!
    One more beer now that the job is achieved... *thumbsup*

    SAlut.

  • Please, do not *g* !!!

    Hey Michel,
    No need to take me so seriously. I don't even take myself seriously. I was just kidding...

    This one was a good object lesson though. I learned (again) that if I don't thoroughly test my code, some bug creeps through. I should have thought about the coordinate wrapping, but if you hadn't pointed it out, I never would have found out about the other conditions that cause the algorithm to fail.

    At any rate, I learned a lot from this one. And that's good news! *thumbsup*

    I'm not so sure about being called Megacrack though... That's evoking some images in my head I'd like to erase...

    steve

  • Hi Steve,

    an incredible piece of code

    I must admit I never thought that the krpano actions could be used for such complex things

    Zitat

    It looks like Klaus uses point averaging rather than center of gravity for the lookto function, you can see this by looking at the green shape. The center of gravity method finds a more pleasing center point. That being said, this new method has the merit of working even for geometries at the zenith and nadir.

    Zitat

    There's a much easier way to do this! Just use Klaus' built-in looktohotspot function and then grab the hlookat and vlookat values:

    internally the hotspot object has a getcenter() function (which will be called by the looktohotspot function ), and it calculates the hotspot center by converting the ath/atv values to 3d vectors, summing all, and then converting the final vector it back to ath/atv (and of course therefore trigonometric functions are necessary )

    but this function is returning an Actionscript 3 object, so it will not be directly usable in krpano (a plugin could use it)... but if needed/wanted I could extend the function to save the calculated values also back to some given krpano variables,


    Zitat

    Since we don't have trigonometric functions available in the krpano language

    are they really needed?
    I could add them (that would be not a big thing), but I'm have always an eye also on the filesize of the krpano.swf and I don't want to blow it up unnecessary...

    best regards,
    Klaus

  • Hi Steve,
    an incredible piece of code
    I must admit I never thought that the krpano actions could be used for such complex things

    Thanks Klaus!

    But frankly, I'm constantly amazed and humbled by the ingenuity of the members of this forum. Just consider:

    the panoramic dioramas of mct
    the double click to zoom action from Michel
    the photo slideshows of Mael B
    the photo slideshows of VN2009
    the xml based thumbnails of Graydon
    the interactive game of Zephyr
    the drums of Tuur
    the profoundly tasteful interfaces of Matrekker

    to name a few of many great examples. I feel blessed to be able to participate on a forum with such amazingly talented, creative, and clever people. You must feel like a proud papa whenever you see work such as these!

    are they really needed?
    I could add them (that would be not a big thing), but I'm have always an eye also on the filesize of the krpano.swf and I don't want to blow it up unnecessary...

    I would not put a priority on trig functions, one could always escape to javascript if they really needed them. The screentosphere and spheretoscreen functions fulfill 99% of the need for trigonometry.

    I'd much prefer to see return values for actions, particularly for use in indices, local variables and debugging support (at a minimum we need to get a message with a line number when an action fails--especially due to a syntax error). All easy stuff, right? kidding....kidding... *g*

    Thanks for such a great and flexible tool Klaus. I'm looking forward to being astounded again many times by you and the other forum members

    steve

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!