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

[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.



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. 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. 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? 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

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>