BUG: 3D Tokens don't keep their proportion XML data on Client side.

[Vass_Dts]

Tested on a 5e clean Campaign with no extensions and nothing but the Monster Manual loaded.


On the GM's side, the tokens have their proper proportions as set by the XML Image Metadata app:
60159

But after connecting as a client using a second instance and share the map, the tokens appear "squashed" as they do when there is no XML associated with the image used for the 3D Token. I've even put on an arakokra from the MM there is check if it's something to do with my home-brew tokens, but apparently it's not.
60160

[Moon Wizard]

Thanks for reporting. @pindercarl has been looking at this one to see what is happening.

Regards,
JPG

[Moon Wizard]

https://www.fantasygrounds.com/forums/showthread.php?80649-Fantasy-Grounds-v4-5-0&p=711165&viewfull=1#post711165

We just pushed a hot fix that should address this. Please run a new Check for Updates, and try again.

Regards,
JPG

[Vass_Dts]

That was the one you rolled back, right? Didn't get the chance to test it then. We had a session today, and the bug also occurred with my players connected. I wanted to make sure, because it wouldn't be the first time that something weird happens only on second instance but not on regular clients. I'll wait for the patch to be patched. :P

[Moon Wizard]

Yeah, unfortunately, I've queued it up for next Tuesday update.

Regards,
JPG

[RosenMcStern]

Will the patch also solve the problem of "squashing" 3D tokens when there is no XML? Version 4.5.0 correctly calculated width and height of the picture, 4.5.1 does not. It resizes the width to predefined proportions. Very annoying.

[RosenMcStern]

Will the patch also solve the problem of "squashing" 3D tokens when there is no XML? Version 4.5.0 correctly calculated width and height of the picture, 4.5.1 does not. It resizes the width to predefined proportions. Very annoying.

[Vass_Dts]

Will the patch also solve the problem of "squashing" 3D tokens when there is no XML? Version 4.5.0 correctly calculated width and height of the picture, 4.5.1 does not. It resizes the width to predefined proportions. Very annoying.

Umm... With no XML you get squashed tokens. To my knowledge that has always been the case. It's not something that changed with 4.5.1. It definitely was that way when I was test driving 4.5.0 beta, and I am 90% certain that was also the case with 4.5.0 Live. But I'd be happily proven wrong.

[Laerun]

Umm... With no XML you get squashed tokens. To my knowledge that has always been the case. It's not something that changed with 4.5.1. It definitely was that way when I was test driving 4.5.0 beta, and I am 90% certain that was also the case with 4.5.0 Live. But I'd be happily proven wrong.

Agreed, one might get "lucky" without the XML image mapping data for coordinates.
The XML data helps FG stretch and bend the image closer to the proper view in regards to proportions in a 2.5D environment, and without this, it's is not doing anything with the image. You are essentially relying on the original scaling and proportions.

[RosenMcStern]

Umm... With no XML you get squashed tokens. To my knowledge that has always been the case. It's not something that changed with 4.5.1. It definitely was that way when I was test driving 4.5.0 beta, and I am 90% certain that was also the case with 4.5.0 Live. But I'd be happily proven wrong.

This was definitely not my experience with the 4.5.0 that went live last week. I inserted a dozen of images as tokens without adding any XML and they all worked fine. With 4.5.1 the same image that worked fine on March 10th (I have the campaign saved) is now squashed if I do not add XML.

I mean, why should you be forced to add XML configuration to tell FG hpw wide is a PNG file? It's a parameter it can calculate when it loads the image. In modern IT, it is considered a very bad practice to force developers to add configuration files to assign a value that can be easily determined by default. You ain't gonna enforce this bad practice, right SmiteWorks?

[Vass_Dts]

It is possible that prior to the update, images were scaled differently. I don't recall that being my experience but it doesn't really matter. And the reason it doesn't matter is that, even if FG correctly scaled an image sans XML (and I'm with you, it should), it would still scale it inside a 5ftx5ft square (for a medium size creature). But there are creatures that are taller than 5 ft. Most humanoids are taller than 5 ft. Or creatures that are wider than 5 ft. Particularly in larger sizes, you get far greater variation in creature dimensions. Without an xml, the images would always be scaled inside a 5x5 or 10x10 or 15x15 square (using 5e standard size definitions). The XML allows an image to go beyond those constraints. To have a humanoid that is 6'1" but that is medium and stands of a 5x5 square. That's why you need the XML data. Because even if it correctly scales an image sans XML in the way you describe it did, that token will still look too short compared to all the other tokens that are already baked in FGU (everything inside the Monster Manual for instance).

My personal objection to all this is that to add the XML, you need to use an external tool--and one that is not easy to find if you don't know where to look. Ideally, it should be part of FG's interface (perhaps part of the Assets manager). But unfortunately for you and I, the majority of users use premade adventures, tokens, monsters, etc. Many of them don't even know how to remove the background from an image to have a png or webp image with transparency in order to make such a token. Which means that, being a small group, SW has to pick their battles (or more accurately, in what order they should do things) and that means that I don't know when and if they are going to fold the XML metadata builder inside FG itself (emphasis on "don't know." They might actually intend to do that next week. Or next year. Or never.)

Me personally, I got the applet. I know how to use it. It doesn't really matter for my use-case. But I still think it would be ideal for all users, if it was part of the FGU's interface.

[RosenMcStern]

I'm not advocating removal of the configuration, just that it adopts a reasonable default when the metadata is not there. And it could very well assume that the total height of the picture is equivalent to 6 feet, it would fit most pictures you find on the internet and make them immediately usable as tokens. 4.5.0 did it, so it is possible. Of course you would still need to add metadata to some tokens, for instance the oversize ones and those with long spears, but for most tokens usable as PC images there is little or no need to use metadata.

[Vass_Dts]

I understood what you suggested. And I agreed with you on that. I'm just saying that's good only as a temporary, on-the-fly solution for when you add tokens without an XML. So that they look at least a bit decent until you add the XML. I'm just explaining that the key-word is "until" you add the XML. You can't not add the XML and have it look good--or at least--equally good as the ones that have the XML.

And the assumption that every medium creature is 6 feet tall is an arbitrary generalization. Sans XML, we both are of the opinion that the software should scale an image in the confines of a 5x5 square. From your description, that's what I gathered it did originally. What it does now, is that it stretches the image on all sides to fill the 5x5 square. That's why the tokens look squashed instead of just shorter that the rest.

[pindercarl]

Will the patch also solve the problem of "squashing" 3D tokens when there is no XML? Version 4.5.0 correctly calculated width and height of the picture, 4.5.1 does not. It resizes the width to predefined proportions. Very annoying.

This issue has been identified and should be fixed in the next release update.