93 replies to this topic

[Afuldan McKronik]

Hit the Deck, on 18 June 2016 - 04:45 PM, said:

On the contrary, this opened up a new topic on how to design a better 'Mech, i.e. to minimize surface area in a given volume. That could mean modifying the shape of current robots but it's more like how to vote for future 'Mechs now that you know (tall) humanoid robots have unnecessarily large surface area and stick out like a sore thumb!

Vote for squat, reverse jointed, stocky 'Mechs!

But just let's skip that, could we get something which resembles a box, like a tank for example?

Or a quad, which would have large legs and small bodys.

[Hit the Deck]

Afuldan McKronik, on 18 June 2016 - 04:49 PM, said:

Or a quad, which would have large legs and small bodys.

you are right, now mention it to Russ

[ScarecrowES]

Afuldan McKronik, on 18 June 2016 - 04:29 PM, said:

While I would agree, there is also the statement of done by feel. Which is what led to this entire rescale in the first place.

Which I am not saying is a bad thing™, just wondering if only some mechs, maybe the outliers in pure pixel count, were done by the formula, then someone went "Well thats just silly small. Lets make an adjustment here and here."

There's a difficulty in doing volume comparison via photogrammetry (using 2D pixels to establish the volume or geometry of a 3D object) if you're only able to use limited views. Consider that each view completely ignores any surfaces that parallel to the view axis, and treats any resulting extrusions as flat surfaces, thus showing only the VISIBLE surface area and ignoring their volume entirely.

To get any level of accuracy out of such a system, you'd need many more views.

However, if you're willing to accept the extreme outliers, you can produce results as we see here and just get a sort of "quick glance" comparison.

As you can see, all of the mech weights tend to follow predictable lines... it's a very linear progression for volume, and a tapering curve for surface area, which is exactly what you should expect, mathematically.

This tells you, at a glance, that the process did it's job.

[Trauglodyte]

Good work.

[Y E O N N E]

Navid A1, on 18 June 2016 - 04:42 PM, said:

While this is correct to some degree... front/side pixel count can at least give you an idea about how large a mech is with regards to other mechs in its weight class.

As an example... the comparisons for the kitfox pretty much confirms what you can conclude just by looking at the kitfox size with regards to a spider for example

You would be much better off if you drew bounding boxes around the legs, torso, and arms individually and took each of their volumes, then added them together. The cube necessarily has to account for fringes, fringes I'm not going to bother shooting at 99% of the time (i.e. arms) because it's wasted damage that could go to a more crucial location.

Hell, even just bounding a box about the torso alone would be superior to drawing a box around the entire 'Mech.

Hit the Deck, on 18 June 2016 - 04:45 PM, said:

On the contrary, this opened up a new topic on how to design a better 'Mech, i.e. to minimize surface area in a given volume. That could mean modifying the shape of current robots but it's more like how to vote for future 'Mechs now that you know (tall) humanoid robots have unnecessarily large surface area and stick out like a sore thumb!

Vote for squat, reverse jointed, stocky 'Mechs!

But just let's skip that, could we get something which resembles a box, like a tank for example?

I always vote chicken!

[Afuldan McKronik]

ScarecrowES, on 18 June 2016 - 04:53 PM, said:

There's a difficulty in doing volume comparison via photogrammetry (using 2D pixels to establish the volume or geometry of a 3D object) if you're only able to use limited views. Consider that each view completely ignores any surfaces that parallel to the view axis, and treats any resulting extrusions as flat surfaces, thus showing only the VISIBLE surface area and ignoring their volume entirely.

To get any level of accuracy out of such a system, you'd need many more views.

However, if you're willing to accept the extreme outliers, you can produce results as we see here and just get a sort of "quick glance" comparison.

As you can see, all of the mech weights tend to follow predictable lines... it's a very linear progression for volume, and a tapering curve for surface area, which is exactly what you should expect, mathematically.

This tells you, at a glance, that the process did it's job.

See, this is why I said, or am I missing something. Thanks!

[Navid A1]

Yeonne Greene, on 18 June 2016 - 05:01 PM, said:

You would be much better off if you drew bounding boxes around the legs, torso, and arms individually and took each of their volumes, then added them together. The cube necessarily has to account for fringes, fringes I'm not going to bother shooting at 99% of the time (i.e. arms) because it's wasted damage that could go to a more crucial location.

Hell, even just bounding a box about the torso alone would be superior to drawing a box around the entire 'Mech.

I'm doing torso comparison since an hour ago...
results to follow.

Very interesting so far...

Edited by Navid A1, 18 June 2016 - 05:19 PM.

[Y E O N N E]

ScarecrowES, on 18 June 2016 - 04:53 PM, said:

There's a difficulty in doing volume comparison via photogrammetry (using 2D pixels to establish the volume or geometry of a 3D object) if you're only able to use limited views. Consider that each view completely ignores any surfaces that parallel to the view axis, and treats any resulting extrusions as flat surfaces, thus showing only the VISIBLE surface area and ignoring their volume entirely.

To get any level of accuracy out of such a system, you'd need many more views.

However, if you're willing to accept the extreme outliers, you can produce results as we see here and just get a sort of "quick glance" comparison.

As you can see, all of the mech weights tend to follow predictable lines... it's a very linear progression for volume, and a tapering curve for surface area, which is exactly what you should expect, mathematically.

This tells you, at a glance, that the process did it's job.

You are going to a level of detail and precision that is unnecessary for how the game works. While a cube about the entire 'Mech is bloody awful, you only need a sum of the approximate volume for each part on the 'Mech, many of which are actually rather regular in terms of geometrical shape. Ergo, subbing in regular shapes and taking those volumes would be close enough. The many extrusions don't typically jut out far enough to matter and treating them as profiles is fine.

You shoot at profiles/silhouettes, and all the damage on a component affects the entire component regardless of how greebly it is or what the impact angle was.

[Afuldan McKronik]

Navid A1, on 18 June 2016 - 05:07 PM, said:

I'm doing torso comparison since an hour ago...
results to follow.

Yay data!

Yeonne Greene, on 18 June 2016 - 05:09 PM, said:

You are going to a level of detail and precision that is unnecessary for how the game works. While a cube about the entire 'Mech is bloody awful, you only need a sum of the approximate volume for each part on the 'Mech, many of which are actually rather regular in terms of geometrical shape. Ergo, subbing in regular shapes and taking those volumes would be close enough. The many extrusions don't typically jut out far enough to matter and treating them as profiles is fine.

You shoot at profiles/silhouettes, and all the damage on a component affects the entire component regardless of how greebly it is or what the impact angle was.

I imagined a MW where you could pick out individual articulators to destroy when you said this. Hnnnngh.

[ScarecrowES]

Yeonne Greene, on 18 June 2016 - 05:09 PM, said:

You are going to a level of detail and precision that is unnecessary for how the game works. While a cube about the entire 'Mech is bloody awful, you only need a sum of the approximate volume for each part on the 'Mech, many of which are actually rather regular in terms of geometrical shape. Ergo, subbing in regular shapes and taking those volumes would be close enough. The many extrusions don't typically jut out far enough to matter and treating them as profiles is fine.

You shoot at profiles/silhouettes, and all the damage on a component affects the entire component regardless of how greebly it is or what the impact angle was.

Certainly... as we discussed back before these patch notes, taking the profile route (photogrammetry) really just leads you back to volume anyway. Volume was the easier and more predictable option.

And we can see, even from just these basic results, that the process did exactly what it needed to do. Sizes are normalized and set on predictable paths, with very few outliers using even this very limited means of assessment.

[Y E O N N E]

ScarecrowES, on 18 June 2016 - 05:16 PM, said:

Certainly... as we discussed back before these patch notes, taking the profile route (photogrammetry) really just leads you back to volume anyway. Volume was the easier and more predictable option.

And we can see, even from just these basic results, that the process did exactly what it needed to do. Sizes are normalized and set on predictable paths, with very few outliers using even this very limited means of assessment.

It takes you to volume only because you want it to, though. If we're trying to design something that's going to be hard to hit, then we don't care about volume because all that matters are the likely profiles it will be shot at, those being front and side, since any other angle is just an amalgamation of those two in some ratio.

I mean, they design tanks to have a small frontal profile first, small side profile second, and frthe top naturally shrinks with those two. What they don't really look at is total volumetric size except for logistical considerations (i.e. it has to fit on a given cargo plane). Having low volume is simply a byproduct of trying to get your primary and secondary profiles as small as possible (and more important than volume for a tank would be displacement/mass).

[Xetelian]

What reason do AWS and VTR have to be so big?

Why is the CPLT as small as 55 ton mechs?

[Hit the Deck]

Xetelian, on 18 June 2016 - 05:54 PM, said:

What reason do AWS and VTR have to be so big?

Because they are humanoid 'Mechs. The AWS is more wide than tall though.

Xetelian, on 18 June 2016 - 05:54 PM, said:

Why is the CPLT as small as 55 ton mechs?

Because it's a stocky chicken walker 'Mech with big boxy "arms" taking a lot of volume.

[Mystere]

Meh! I am not even remotely convinced of this pixel count analysis. What needs to be done is for someone to create 1/100 scale 3D-printed models and then calculate volume via the water displacement method.

Once done, all 3D models should then be sent to me.

Edited by Mystere, 18 June 2016 - 06:35 PM.

[Y E O N N E]

Mystere, on 18 June 2016 - 06:35 PM, said:

Meh! I am not even remotely convinced of this pixel count analysis. What needs to be done is for someone to create 1/100 scale 3D-printed models and then calculate volume via the water displacement method.

Once done, all 3D models should then be sent to me.

No u. I want the Locust!

[Mystere]

Yeonne Greene, on 18 June 2016 - 06:41 PM, said:

No u. I want the Locust!

No!



<You took the bait, hook, line, and sinker.>

Edited by Mystere, 18 June 2016 - 06:45 PM.

[Navid A1]

Torso Comparison in terms of Volume and Front-side Visible surface:

[Bishop Steiner]

Navid A1, on 18 June 2016 - 06:45 PM, said:

Torso Comparison in terms of Volume and Front-side Visible surface:

Lol.... KGC is a frikking frisbee with arms and legs.

(And the DWF is a Borg Cube... no shock on those torso counts, or why)

Edited by Bishop Steiner, 18 June 2016 - 06:57 PM.

[Hit the Deck]

Navid A1, on 18 June 2016 - 06:45 PM, said:

Torso Comparison in terms of Volume and Front-side Visible surface:

One question, why is it pixel squared? Doesn't the pixel count already represent the surface area?

[Navid A1]

Hit the Deck, on 18 June 2016 - 06:54 PM, said:

One question, why is it pixel squared? Doesn't the pixel count already represent the surface area?

Yup... my mistake.