Floating point limitations

I know I'll get a ton of crap, but it's a legitimate question.

I bought an Asset which I enjoy a lot, the problem is that the GameObject it generates is limited to a certain size, the developer has informed me that its due to floating point limitations. Gathering whatever knowledge I have it probably has to something do with limited amount of bytes to assign post-comma values, which makes it either drop last numbers, fatally crash or generate non-sense numbers. I however, would sooner or later love to expand that. So:

1. Generally speaking, how possible/easy/hard is it to postpone (to bigger numbers) the floating point limitation threshold? It this amendable? If so, generally speaking how easy/hard is it? Could I jump import a library or is it something that is so hardcore baked into C#/Unity that I can stop dreaming?
2. Absolutely unrelated question. Is it possible for me to know what size a GameObject is? This Asset takes quite up of my memory for valid reasons, is it possible for me to programmatically find out and compare the sizes. I know I could just disable and then enable the Asset and look at memory usage, but I would like to access it in more code-related manner.

 

Question 1:
generally speaking there is another data type with higher precision. It's called 'double' rather than the general 'single float'. It takes up 64-bits instead of 32-bits. So its mantissa (the sig value range) is 52 bits (53 implicit) instead of 23 bits (24 implicit).

BUT, there is a problem here.

1) Unity uses single floats in nearly all of its API. GameObjects themselves are comprised of Transforms that use Vector3's and Quaternions which are all bound to a single-precision float. And you can't replace them with doubles. That'd require a complete rehaul of the engine by Unity.

2) One of the big reasons single floats are used is a consistency factor between the calculations performed on the CPU by the engine, and the calculations performed on the GPU. See... not all graphics cards have double precision compute. Consumer grade cards may forego them completely, or in the cases where they do have them (they're becoming more common now a days in consumer cards), they still perform slower because well... you need more bitdepth for them, effectively halving the work space since a double is twice the size of a single. So you can't perform as many concurrent calculations with them.

The general idea is that a video game generally doesn't need all that precision. Things like simulations and scientific calculations need them (and is why for the longest time double support on graphics cards were mostly found in high end cards like Quadro cards).

So... in effect. If your float limitation is because this asset you're talking to is limited by a float somewhere on the Unity API side (such as the Transform and the sort). Yeah, you can stop dreaming now.

Question 2:
Not super easily...

Considering that the GameObject really is a composite of multiple components and assets. Its size gets a little weird to calculate.

You have to measure the size of all the managed objects (the GameObjects, the Components, etc). But you also need to measure the size of the Unity side of things (there is the managed portion of a GameObject/Component, but there is all the unmanaged object on the Unity side of the engine that is correlated with it. When you call Destroy you're destroying the unmanaged unity object, the C# managed object remains in memory. To give you an idea of the distinctness between the 2).

But that stuff is tiny compared to what usually takes up most of the memory. And that is the media/graphical assets. The mesh, textures, shaders, audio clips, and all that hub-bub. And that stuff gets weird in calculating the space of because of many things.

For example... your GameObject might have a mesh on it, but when you clone it, that mesh will likely NOT get cloned. And instead both GameObjects will share the same mesh (unless you otherwise tell it not to) so as to save memory. So if you say calculated the size of both GameObjects... then summed them... you actually would get a value larger than the actual memory used! (this goes for a lot of the assets on the GameObject including textures and what not)

There's also WHERE the memory is. For example a texture can exist in both RAM and VRAM. VRAM because that's how it gets rendered... but you may likely have it in RAM for manipulation purposes. Your texture might actually be split in both regions for whatever reason. And also if you say copy that texture into yet another copy of working memory for some script you wrote to animate it, it's taking up yet even more memory that's not easily noticeable since that copied texture isn't actually associated with the GameObject.

And that's actually another issue in figuring this out. What is considered "part of the GameObject" when calculating its size?

...

...

With all this said.

What is the limitation of this asset you speak of?

You say:

Size of what? How big?

If you don't know what dependencies cause the single-float restriction (like if it's Transform related), maybe we can help figure it out if you let us know what asset you're even talking about.

[edit]

I just noticed which user you are. This has come up in the past. You're always very vague about the specifics of what you're working with. These specifics can help us give MUCH BETTER answers if you'd just supply them up front (or ever).

You have a question about an Asset? OK... link the asset from the asset store and say "I'm using Asset X (link included) and I'd like to scale its mesh to N units in size. But I seem to have a float constraint issue. Can you confirm this?"

Otherwise we're left to work in theory.

And in theory... well, we can go on for hours with long diatribes (see above) that may or may not help you. Or worse confuse you, send you the wrong direction, make assumptions that don't actually pertain to you, etc etc etc.

As well as just generally wasting our time as we poke, prod, make assumptions, and write long diatribes that may or may not be necessary.

For example, this thread:
https://forum.unity.com/threads/return-ones-own-variable-as-parameter.775400/

As I said over there: