Moving Geometry Sometimes Doesn't work

[jab0707]

The moving geometries functionality (assigning a moving geometry as geom.pts_mv which is a n X (3*m) where n is the nodes and m is the number of different moved geometries) sometimes doesn't work. In the attached files one labeled works.mat has no issue, but the one labeled notWorks.mat has different node numbers and positions but is otherwise structured similarly but does not work. map3d will either refuse to plot it, crash, or plot a highly distorted version of it. I have confirmed that the geometries look appropriate in matlab

data.zip

[jab0707]

I loaded each individual geometry into MAP3d separately and they all look fine, it is only when I assemble them into a moving geometry that I get an issue.

[bryanworthen]

All right, I'll take a look. (I don't remember anybody using moving geometries yet.)

I may not have a chance before tomorrow - can you clarify "different node numbers"? That doesn't mean a variable number of points, does it?

[jab0707]

Sorry for the slow response. By different number of nodes I mean that the second moving geometry is a different geometry altogether with a different number of nodes than the geometry that does not work. However I do know that for the notWorks.mat geometry, if I were to extract any single of the geometries from the series of moving points it would work no problem. It is only when stringing this particular set of geometries together that I get an issue.

I have making fairly extensive use of the moving geometries feature and plan to do so even more going forward. I have enjoyed it so far, despite occasional weird bugs like this.

[bryanworthen]

I haven't had a chance to dig in yet, but I'm pretty sure I implemented it with an assumption that each frame of the geometry had to have the same number of nodes (and possibly the same connectivity?). I feel like I did this because the time series data only has one set of nodes, and to map the data to a geometry with a different shape would be confusing (at best). If, on the other hand, you're not mapping data to it, then that's a different story.

…

On Thu, Sep 17, 2020 at 5:29 PM Jake Bergquist ***@***.***> wrote: Sorry for the slow response. By different number of nodes I mean that the second moving geometry is a different geometry altogether with a different number of nodes than the geometry that does not work. However I do know that for the notWorks.mat geometry, if I were to extract any single of the geometries from the series of moving points it would work no problem. It is only when stringing this particular set of geometries together that I get an issue. I have making fairly extensive use of the moving geometries feature and plan to do so even more going forward. I have enjoyed it so far, despite occasional weird bugs like this. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#43 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKDF3VP72G5PGK7HUCADYDSGKLW3ANCNFSM4QVUJMLQ> .

[jab0707]

I do have data. I have noticed that the moving geometries do not work if there is no data. (That would be awesome if we could have moving geometries that both didn't have data and could change the number of nodes)

But for these examples I sent, the moving geometries internally have the name number of nodes per movement. The difference in number of nodes is between the two example files.

[bryanworthen]

Ok, sorry, read too fast.

Initial assessment/notes:

notWorks:
map3d thinks it is time-based point array, m(cols)=240, n(pts)=300 (timesteps=80)
map3d thinks notworks-data.mat has 240 leads
initial hypothesis: notworks pts_mv is transposed.

[bryanworthen]

And transposing it correctly looks like this:

[bryanworthen]

Did you get a chance to see if my transpose hypothesis was correct? Bryan

…

On Thu, Sep 17, 2020 at 5:55 PM Jake Bergquist ***@***.***> wrote: I do have data. I have noticed that the moving geometries do not work if there is no data. (That would be awesome if we could have moving geometries that both didn't have data and could change the number of nodes) But for these examples I sent, the moving geometries internally have the name number of nodes per movement. The difference in number of nodes is between the two example files. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#43 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKDF3QWF3ZDS62X3APTJXLSGKOVHANCNFSM4QVUJMLQ> .

[jab0707]

Sorry for the long delay. It looks like transposing does fix the issue. I was under the impression that the .pts_mv field had to be arranged in a m X nt matrix where m is the number of nodes, n is 3 (x,y,z coordinates) and t is the number of time instances. Then each grouping of three columns would be a single geometry for a given time instant. I have had that format work in some cases and not others. (Transposing of course would just flip that convention to be a nt X m matrix). Is there a reliable format to not need to have to transpose back and forth?

[bryanworthen]

Hmmm, if that's what it says in the documentation, I can probably change the ordering. However, if there are other users using it already, it would be a breaking change for them. It would prefer to be able to auto-detect, like we can with the pts (which says "if the dim I wasn't expecting to be the 3 is 3, transpose"), but here the best I can do is say "if one of the dims isn't a multiple of 3, transpose". UNLESS, I redesign another thing that isn't pts_mv (which is short for moving points), call it animated_pts, and stack it the other way, such that one dim is 3 and the other dim is num_pts * num_frames... Bryan

…

On Mon, Jan 25, 2021 at 11:40 AM Jake Bergquist ***@***.***> wrote: Sorry for the long delay. It looks like transposing does fix the issue. I was under the impression that the .pts_mv field had to be arranged in a m X n*t matrix where m is the number of nodes, n is 3 (x,y,z coordinates) and t is the number of time instances. Then each grouping of three columns would be a single geometry for a given time instant. I have had that format work in some cases and not others. (Transposing of course would just flip that convention to be a n*t X m matrix). Is there a reliable format to not need to have to transpose back and forth? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#43 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKDF3WCHYUTZYWE2NTAHLDS3W3LPANCNFSM4QVUJMLQ> .