Pre-defining the scale and positioning of images in 3D space

[ddavison]

Note: This is meant for community developers, Forge crafters, and people who want to create their own homebrew content that interacts with the 3D camera view mode that is currently in our TEST channel build for Fantasy Grounds Unity version 4.5.0.

Fantasy Grounds uses xml metadata files to predefine the scale, position, and clipping of images that are shown in the 3D Camera View Mode. You can use the same tool to predefined any images you want to use. Just place these in the same location as the original image file.

Walk-through
7Y_BqXN1r6Q

Download for image metadata tool:
Windows Version (https://www.dropbox.com/scl/fi/gwisyptgjzu68ezxgpkli/FG-Image-Metadata-Builder.zip?rlkey=m2a9dk7zbtopot841xfmj1u1o&dl=0)
Mac OS Version (https://www.dropbox.com/scl/fi/3yx3d3qbef1vya3qynlby/MacOS.app.zip?rlkey=lryaezprrn5mpom9xpulp012f&dl=0)
Linux Version (https://www.dropbox.com/scl/fi/otm5zuei7u4zj5oo3bv5z/FGImageMetaDataToolLinuxBuild.rar?rlkey=ffugm6t1vk 3bw7k8p1swgecb4&dl=0)

[Vass_Dts]

Yeah, unfortunately that's not gonna run on a Mac. :P

[rhagelstrom]

An issue I see with float is it gives the appearance that a creature is somewhere it is not. For anything that is floating, it looks airborne but in game mechanically it is at token height 0. Since setting the token height also moves the image up/down, wouldn't a better solution be to use that float value to set the default token height when added to the map and not offsetting the image instead of offsetting the image position artificially to give the illusion of flying when it is actually not?

I see this scenario coming up:

Player: "Oh its flying, how high up is it?"
GM: "It's not it's right in front of you"
Player: "Why does it look like it's flying?"

or

creature is flying.
Player: "I cast fly and fly up to attack it"
Player: Moves token to the image
Player: "Why am I getting disadvantage on this roll?"
GM: "Because you are too far away, the creature is actually down here, it just looks like it is up there"

[ddavison]

Depending on the image, the float offset is normally about 1/4th if a grid square. It just means it won’t draw the beholder laying on the ground.

If it is flying up 5’ or more, there will be a height indicator shown that players will see.

[Vass_Dts]

But it seems off in some cases:
(Can’t seem to be able to post an image right now)
An ancient red dragon appears to be well above the reach of medium sized character even though it’s supposed to be grounded.

[ddavison]

But it seems off in some cases:
(Can’t seem to be able to post an image right now)
An ancient red dragon appears to be well above the reach of medium sized character even though it’s supposed to be grounded.

What is the source for the ancient red dragon? Ruleset and module name?

[rhagelstrom]

But it seems off in some cases:
(Can’t seem to be able to post an image right now)
An ancient red dragon appears to be well above the reach of medium sized character even though it’s supposed to be grounded.

I had the same issue in that I can't post an image. Forums uploads seems broken again

[ddavison]

I see the issue with the D&D Monster Manual version of the Ancient Red Dragon. (S)he is in a flying pose, but (s)he seems to be up very high off the ground.

[rhagelstrom]

Depending on the image, the float offset is normally about 1/4th if a grid square. It just means it won’t draw the beholder laying on the ground.

If it is flying up 5’ or more, there will be a height indicator shown that players will see.

This probably would be easier to explain if I could post an image but we will try it without.

Why not display the image of the beholder on the ground if it is actually on the ground? If the beholder should be floating, then its token height should be set, which would make the image then look like it is floating and not on the ground.
It looks like you guys have gone through and defined with that tool everything that should be hovering/flying, so why not make it actually hover/fly within the game by setting the token height? That would be a very nice add because then every time I have something in my game that hovers, I don't have to go and set the token height to 5 or whatever because everything defaults to 0, you just set the token height for me. Also if I set my token height to 5 to hover it, with the way you guys have it now, it'll just push the image up even further.

With that dragon in particular or anything that floats really, If I want it to look like it's coming in for a landing/on the ground, I'd have to set the token height to negative. I don't understand why the graphical representation of the game board isn't consistent with how the game board is actually set up.

[ddavison]

We want it to be consistent with how it looks for minis. They have flying stands for floaters that are not standing. I have never seen a beholder sitting on the ground. The assumption is it is floating above the ground in the 5’ space.

What you are describing doesn’t match with my experience gaming.

That said, large floaters do appear to be hovering higher than intended but n the current build.

[LordEntrails]

IMO, a beholder shouldn't be on the ground. I would assume that a floater would probably place the center of the image height 1/2 the number of squares the token takes up (based on the metadata and size).

But would really have to work through things, as well, it would depend on the artwork.

Let's see if I can work through some of the math...
For a medium creature with a height and width ~4 ft, this would result in the 0.5 ft of float. But for a medium with a height of 2 feet a 1.5' of float. How about for a large sized beholder that is what, an 8 ft sphere? That would give about 1 foot of float. Hmm, not sure that's the best way to calculate.

If float is simple a 1/4 grid gap between the floor and the bottom of the image...? would be consistent, but would that work for a flumph? I a flumph is medium, maybe 2 high and 4 feet wide? Probably should float near the top of it's 'cube'...

Maybe the answer is to be able to control the float? Similar to justification, top, bottom, center?

[ddavison]

Yes, let's revisit this one we fix the current spacing issue. In the example image below, the beholder zombie is floating about twice as high as we originally intended. The image is 800 pixels and the float was set to 200 pixels. I think it might be getting doubled for large 2x2 creatures in the current build. We can also look to reduce it to a lower float, such as 1/8th instead of 1/4th. Ultimately, we can set it at whatever we want... we just want them to look consistent and match with expectations.

59889

BTW, image attachments should be fixed now. I also have to fix that guy's image because he has some white areas that should be transparent.

For an Ancient Red Dragon, take a look at the one in the SRD Bestiary and see if you like that better than the official D&D Monster Manual one.

[Vass_Dts]

It sounds like the fix would be to have the float pixel amount remain fixed instead of scaling with creature size.

Anyway, I fiddled around with some humanoid NPC art. The 3d Token look off. Too short and stocky. I tried to see if could play with the image dimensions in Photoshop, but the results were not satisfactory (I did not exhaust my ideas though, so. Which means, as you already stated, we need that external program to generate properly sized 3d tokens. Thing is, I can't do that, because I'm on a Mac. :p Which leads me to the question of not if a Mac version of the program will be made, but more importantly, if we will be able to define said dimensions from within FG.

[rhagelstrom]

Still getting this error when trying to upload images


Your submission could not be processed because a security token was missing.

If this occurred unexpectedly, please inform the administrator and describe the action you performed before you received this error.

[Zacchaeus]

Still getting this error when trying to upload images

Try clearing your cache or use a different browser.

[rhagelstrom]

Same error different browser. Same error different machine, different OS

[LordEntrails]

It sounds like the fix would be to have the float pixel amount remain fixed instead of scaling with creature size.

Anyway, I fiddled around with some humanoid NPC art. The 3d Token look off. Too short and stocky. I tried to see if could play with the image dimensions in Photoshop, but the results were not satisfactory (I did not exhaust my ideas though, so. Which means, as you already stated, we need that external program to generate properly sized 3d tokens. Thing is, I can't do that, because I'm on a Mac. :p Which leads me to the question of not if a Mac version of the program will be made, but more importantly, if we will be able to define said dimensions from within FG.
I doubt it. I think what Mac developers are going to have to do is create the xml manually :( As this tool really only creates the xml to be used by FG. I've not used the tool yet, but if no one else is able to provide a few samples for you, I can look into doing that. Let me know.

[Vass_Dts]

I doubt it. I think what Mac developers are going to have to do is create the xml manually :( As this tool really only creates the xml to be used by FG. I've not used the tool yet, but if no one else is able to provide a few samples for you, I can look into doing that. Let me know.

I'll admit your statement took me by surprise. Why do you doubt the tool be made for Macs? It appears to me that, unless this function gets folded within FGU's own UI (which, I'm of the opinion that it should, as it seems pretty vital), this tool is the only recourse one has to make their own tokens display correctly in 3d Camera mode if they don't know XML. Mac users are just gonna have to learn to do it manually? :confused: Don't get me wrong, I thank you for your offer of course. I'm just surprised if indeed the tool is meant to be Windows only for ever. Unless there is something I'm completely missing.

EDIT: Note, that I don't understand how this is only for "developers." Every DM that has their own NPCs and their own art and their own tokens to use in their games will need it. Not all of us run pre-made adventures or use stuff exclusively from the Monster Manual(s).

[LordEntrails]

You're probably right that it will need to be part of core FG. I was basing my thoughts on this in terms of the initial statement from Doug in the OP. Until that time (which I would not hazard a guess when it will be in core FG), I doubt SmiteWorks would work to put the tool into a Mac compatible app before then. In the meantime, if you want xml samples, let me know.

Just for a point of reference, Steam reports (depends on source) that about 97% of their users (gamers) use Windows, and 2% Linux, and 1% MacOS. I have no idea what the numbers are for FG, but it does put an interesting thought on Mac and Linux support and how viable supporting all 3 platforms is as a business model.

[ddavison]

As this feature is in our beta TEST channel, we decided to use an external tool to build out the XML metadata instead of holding up a release for a future integrated version within FG. The long-term solution is to embed that functionality within FG. The tool was built in Unity, so a Mac build may work. There is a dependency upon a SkiaSharp library. When I built a version for Linux, one of our community devs was able to use it after they also installed SkiaSharp.

Try this and let me know if it works for you:
Mac OSX Build (https://www.dropbox.com/scl/fo/e0iiq5ceytilb9mvcah6r/h?rlkey=iibyt5hpqzuhwafnvcnycr683&dl=0)

Here is an example of the XML generated for the Aboleth in the SRD. The top/left and bottom/right help identify the width and height of the image. The Measurement Region can be the same as the full image's top/left and bottom/right if you want, and then you need to supply either the width or the height in real world feet that it should be drawn. The offset is used to adjust the placement of the feet.

Example #1: Aboleth from SRD
In the example below, there is an area within the image that is measured and determined that it should draw as if it is 20 feet wide. The expected grid size is 2, meaning that it thinks a normal Aboleth should be drawn in a 2x2 square as a large creature. Yes, this creature will extend beyond those constraints by a considerable amount. If you have a Huge aboleth, then it would calculate it 1.5X the height as it expands it from a 2x2 creature to a 3x3 creature.



<?xml version="1.0" encoding="utf-8"?>
<root>
<billboard>
<top>0</top>
<left>0</left>
<bottom>1000</bottom>
<right>1011</right>
<width>20</width>
<offset>-76,-47</offset>
<measurementRegion>
<top>31</top>
<left>33</left>
<bottom>530</bottom>
<right>974</right>
</measurementRegion>
<expected_grid_size>2</expected_grid_size>
</billboard>
</root>


Example #2: Acolyte from the SRD
This creature has a height of 5.3 feet tall with the measurement coordinates marked from the head to the toes. It uses height for the scale and ignores the width. It is also offset so it draws the acolytes feet at the floor.



<?xml version="1.0" encoding="utf-8"?>
<root>
<billboard>
<top>0</top>
<left>0</left>
<bottom>1000</bottom>
<right>555</right>
<height>5.3</height>
<offset>20,-19</offset>
<measurementRegion>
<top>40</top>
<left>252</left>
<bottom>977</bottom>
<right>423</right>
</measurementRegion>
<expected_grid_size>1</expected_grid_size>
</billboard>
</root>

[ddavison]

I updated it to fix a few issues and put links to the Windows, Linux, and Mac versions in the first post.


Floating creatures now float only about 1 foot off the floor for each time you click the Float button. You must define the measurement height and feet location first.
The expected grid size now support 0.5, which is what you should use for Tiny creatures.

[Jiminimonka]

We want it to be consistent with how it looks for minis. They have flying stands for floaters that are not standing. I have never seen a beholder sitting on the ground. The assumption is it is floating above the ground in the 5’ space.

What you are describing doesn’t match with my experience gaming.

That said, large floaters do appear to be hovering higher than intended but n the current build.

Large floaters should never be seen in FG... ;) :) sorry its early on a friday

[ddavison]

Nice.

Run an Update and check out the Adult Red Dragon, Beholder, and other flying creatures from the D&D MM and modules. They should be better now.

I will need to update a few from the SRD and push an Update for those later today.

[masteryogurt]

I can confirm this works for me on MacOS Sonoma 14.3.1. I had to change security settings to run the tool, which I fully expected. The pop-up / drag and drop did not work, but I am able to load images by copying and pasting the file path.

[Vass_Dts]

I can confirm this works for me on MacOS Sonoma 14.3.1. I had to change security settings to run the tool, which I fully expected. The pop-up / drag and drop did not work, but I am able to load images by copying and pasting the file path.

Hi, can you tell me what settings you changed? I get a message "Not possible to open this app" or something like that. But I believe my security settings are okay.

EDIT: Nevermind, fixed it. Had to do some terminal chmod shenanigans.

[masteryogurt]

I used the application version from Post #20 (https://www.fantasygrounds.com/forums/showthread.php?80375-Pre-defining-the-scale-and-positioning-of-images-in-3D-space&p=708512&viewfull=1#post708512), above, in this thread.

I got a security flag each time it tried to run a new Unity package, so I used Settings. It was easy, but I needed to use terminal and followed this guide on OSX Daily. (https://osxdaily.com/2016/09/27/allow-apps-from-anywhere-macos-gatekeeper/) I reverted to normal security settings once I was done.

I couldn't get the version in the first post to run at all.

Did your way get drag and drop to work?

[Tailz Silver Paws]

This looks very handy, be nice to be able to do the same thing for general tokens.

[LordEntrails]

Next time you are looking at the code of this tool, a couple of suggestions for consideration;
- Have visible indicators for the various positions. Such as a red box for the clip region. Blue for the measurement region. White height/width indicators (bars on the side?)and a center point icon. (I know you give the coordinates, but a visual indicator would be very useful for some of us!)
- Ability to load in a current image and XML file to see what the settings are. Very useful with the above enhancement. This would help with issues identifying undesired behaviors
Thanks :)

[ddavison]

It does auto load the current xml if you drag an image in that has a matching xml file at the same location. It just doesn’t have the visual indicators at this time.

This would definitely be helpful. I wasn’t sure how long this took would need to exist as a separate tool versus something built into FG.

[LordEntrails]

It does auto load the current xml if you drag an image in that has a matching xml file at the same location. It just doesn’t have the visual indicators at this time.

This would definitely be helpful. I wasn’t sure how long this took would need to exist as a separate tool versus something built into FG.
Good to know about it loading the xml. Never tried, just assumed!

[cwsoots]

First, thanks for this tool. It works great for fine tuning the height differences in my PC and NPC images (e.g., properly sized firbolg vs. a halfling).

Would it be possible to add a visible boundary box when setting the Clip Region? See the linked example below. I often find it challenging to clip close to the object's edge and not clip off parts of the image that extend beyond the clip region. Something like a visible clip region box would help tremendously. Thanks for your consideration!

https://www.dropbox.com/scl/fi/nv7rfrwhrp48edhdfgs57/Boundary-box-example.jpg?rlkey=2iz6oufss05vzfp8c5wei8elg&st=hukelvm2&dl=0

[LordEntrails]

You know you don't need to set the clip region if the image doesn't have multiple characters/figures in it right?

[pindercarl]

You know you don't need to set the clip region if the image doesn't have multiple characters/figures in it right?

The clip region does not remove parts of the image. The clip region defines the height and width of the token. This region is used in combination with expected grid size and height to determine the size of the token. If your image doesn't have any extraneous bits like wings or a tail, then you don't need to set the clip region.

[EDIT: the clip region clips the image, the measurement region sets the token size, see post below.]

[cwsoots]

The clip region does not remove parts of the image. The clip region defines the height and width of the token. This region is used in combination with expected grid size and height to determine the size of the token. If your image doesn't have any extraneous bits like wings or a tail, then you don't need to set the clip region.

Thanks for the clarification! I assumed that it was used to get rid of any unused areas of the original image so the token can be better scaled in the available space. Looking back at the Developer Video, I can see now that it's generally not used. I'll try and create the metadata without it and see if there's any noticeable difference.

[deer_buster]

Note: This is meant for community developers, Forge crafters, and people who want to create their own homebrew content that interacts with the 3D camera view mode that is currently in our TEST channel build for Fantasy Grounds Unity version 4.5.0.

Fantasy Grounds uses xml metadata files to predefine the scale, position, and clipping of images that are shown in the 3D Camera View Mode. You can use the same tool to predefined any images you want to use. Just place these in the same location as the original image file.

Walk-through
7Y_BqXN1r6Q

Download for image metadata tool:
Windows Version (https://www.dropbox.com/scl/fi/gwisyptgjzu68ezxgpkli/FG-Image-Metadata-Builder.zip?rlkey=m2a9dk7zbtopot841xfmj1u1o&dl=0)
Mac OS Version (https://www.dropbox.com/scl/fi/3yx3d3qbef1vya3qynlby/MacOS.app.zip?rlkey=lryaezprrn5mpom9xpulp012f&dl=0)
Linux Version (https://www.dropbox.com/scl/fi/otm5zuei7u4zj5oo3bv5z/FGImageMetaDataToolLinuxBuild.rar?rlkey=ffugm6t1vk 3bw7k8p1swgecb4&dl=0)

I really wish City Hall would be used ONLY for announcements, not discussion topics...

[pindercarl]

Thanks for the clarification! I assumed that it was used to get rid of any unused areas of the original image so the token can be better scaled in the available space. Looking back at the Developer Video, I can see now that it's generally not used. I'll try and create the metadata without it and see if there's any noticeable difference.

To clarify the clarification, the measurement region is used as described to determine the size of the token. The clip region does, in fact, clip the rendered portion of the image. It had been a while since I looked at the implementation and I read it wrong.

[rigerco]

Is there an official support forum thread for this topic? I'm having some issues with "large" creature image sizes on screen.

[LordEntrails]

Is there an official support forum thread for this topic? I'm having some issues with "large" creature image sizes on screen.
Nope, just start a new thread in the House of Healing.

[rigerco]

OK. Will do, I just didn't want to start a new one, or post here, if there was an existing thread elsewhere.