PTJ Verse - Speed Upgrade

[Viott]

Here is the accepted calculation:

Manager Kim cuts the bullet

vsbattles.fandom.com

The characters that need to be upgraded are:


Big 3

• Hansoo Seong (Comparable to Manager Kim)
• Jincheol Park (Comparable to Manager Kim)​

2nd Generation

• Johan Seong (He was able to block Manager Kim's attack)​
• Jerry Kwon (He was able to dodge Manager Kim's attacks)
• Warren Chae (He was able to attack Manager Kim)
• Eli Jang (Comparable to Warren Chae)
• Daniel Park True Body (Comparable to Johan Seong)
• Daniel Park Perfect Body (Comparable to Daniel Park (True Body))
• Zack Lee (He blocked Johan's kick)
• Mandeok Bang (He defeated Jerry Kwon)
• Vasco (He was able to damage Mandeok Bang)
• Vin Jin (Comparable to Vasco)
• Hudson (He was able to damage Eli Jang)
• Yuseong (He was able to damage Johan)
• Samuel Seo (Comparable to Eli Jang)
• Jake Kim (He was able to defeat Samuel Seo)
• Xiaolung (Comparable to Jake Kim)
• Taejin Cheon (He defeated Vin Jin)

1.5 Generation

• Gun Park (He beat Johan Seong)
• Goo Kim (Comparable to Gun Park)
• Sinu Han (He blocked Eli Jang and Warren Chae's attack)

1st Generation

• James Lee (Beat all the 1st Generation kings)
• Seokdu Wang (He defeated Warren Chae)
• Jichang Kwak (He blocked Daniel Park’s punch)
• Taesoo Ma (He is Hudson’s master and faster than Hudson)
• Gongseob Ji (He is Zack Lee’s master and faster than Zack Lee)
• Jaegyeon Na (He is faster than Daniel Park)
• Yujae Seon (Comparable to Jaegyeon Na)
• Seongji Yuk (Comparable to James Lee)
• Jinrang (Comparable to Jaegyeon Na)
• Gitae Kim (He defeated Jinrang)

0 Generation

• Tom Lee (Comparable to Manager Kim)
• Jinyoung Park (Comparable to Tom Lee)
• Charles Choi (He defeated Jichang Kwak)
• Shingen Yamazaki (Comparable to Gun Park)
• Gapyrong Kim (He is a legend of the 0th Generation, comparable to Tom Lee)

Staff Acceptance: Elizhaa, Firestorm808, FinePoint

Staff Rejection:

 

[Elizhaa]

If there is no major inconsistencies with the speed, I guess it is fine.

 

[Vzearr]

This feat displays inconsistency, the dude is crying in one panel and in the next panel his face is contorted to the side, meaning scaling to his nose bridge is flawed as the distance moved by him creates larger distance between him and the bullet, meaning the bullet moved more distance. Onto my second reasoning as to why the calc is flawed, we use the diameter of the bullet here which is closer to the Point of View of the camera then the slash, using something closer to the camera to scale something further than the camera actually makes the thing further than the camera look much larger. Onto the third reason, once the bullet is touched, the velocity slows down significantly, so using the end of the bullet as scaling is flawed because the bullet has already slow'n down due to being cut from the front. I also declare this calculation, debunked.

 

[Viott]

This feat displays inconsistency, the dude is crying in one panel and in the next panel his face is contorted to the side, meaning scaling to his nose bridge is flawed as the distance moved by him creates larger distance between him and the bullet, meaning the bullet moved more distance.

The fact that a bullet travels a longer distance does not mean the calculation cannot be used. Because the result comes out slightly lower than it should be. As long as the result does not come out higher than it should, this can be used.

Onto my second reasoning as to why the calc is flawed, we use the diameter of the bullet here which is closer to the Point of View of the camera then the slash, using something closer to the camera to scale something further than the camera actually makes the thing further than the camera look much larger.

To find the distance between the tip of the bullet and the character’s face, I calculate how far the base of the bullet and the character’s face are from the camera using angsize, then subtract these two values and subtract the bullet’s length from the result. It’s that simple.

Onto the third reason, once the bullet is touched, the velocity slows down significantly, so using the end of the bullet as scaling is flawed because the bullet has already slow'n down due to being cut from the front.

The bullet’s deceleration is not important. If the bullet has moved in the panel where it is cut, then the measured distance would be greater than the distance actually traveled by the bullet. This means the result will come out lower than it should be. Therefore, the calculation can still be used.

I also declare this calculation, debunked.

You couldn’t debunk anything.

 

[Vzearr]

The fact that a bullet travels a longer distance does not mean the calculation cannot be used. Because the result comes out slightly lower than it should be. As long as the result does not come out higher than it should, this can be used.

What does this even mean, your calculation highballs the feat. You're applying AP highballs to speed highballs when they're inherently different things. An AP highball includes a larger distance, and speed highball includes a lower distance generally.

To find the distance between the tip of the bullet and the character’s face, I calculate how far the base of the bullet and the character’s face are from the camera using angsize, then subtract these two values and subtract the bullet’s length from the result. It’s that simple.

Viott, I can read, you seemingly didn't understand my debunk.

Imagine you’re looking at two blocks, one right next to your eyes and one further away, with a knife sitting between them. If you try to use the close block as a reference to size the knife, you’ll make the knife look much bigger than it really is, because using something closer to your eyes to scale something further away always inflates the size of the farther object.

The bullet’s deceleration is not important. If the bullet has moved in the panel where it is cut, then the measured distance would be greater than the distance actually traveled by the bullet. This means the result will come out lower than it should be. Therefore, the calculation can still be used.

You scale the base to the face, the bullet decelerates as soon as it get's hit at the tip, so your calculation is wrong.

 

[Viott]

What does this even mean, your calculation highballs the feat. You're applying AP highballs to speed highballs when they're inherently different things. An AP highball includes a larger distance, and speed highball includes a lower distance generally.

The calculation is not a highball but a lowball. As I said, finding a distance greater than the one the bullet should have traveled makes the result come out lower than it should be.

Imagine you’re looking at two blocks, one right next to your eyes and one further away, with a knife sitting between them. If you try to use the close block as a reference to size the knife, you’ll make the knife look much bigger than it really is, because using something closer to your eyes to scale something further away always inflates the size of the farther object.

Look closely. The cut bullet fragment is not far from the white line. It's right next to it.

You scale the base to the face, the bullet decelerates as soon as it get's hit at the tip, so your calculation is wrong.

As I said, the bullet’s deceleration doesn’t matter. If there’s no way to determine how far the bullet actually traveled, the distance found by the calculation can be used. Because if the bullet moved in the panel where it was cut, the distance calculated will be larger than the distance the bullet actually traveled. That means the result will come out lower than it should. Therefore, the calculation can still be used.

 

[Vzearr]

The calculation is not a highball but a lowball. As I said, finding a distance greater than the one the bullet should have traveled makes the result come out lower than it should be.

Viott bro, this is NOT how that works.

If the bullet is supposed to go this far ———
but it went this far —————————————————
Then the distance moved is larger making the end speed of the character slower. Because Speed = distance / time.

Look closely. The cut bullet fragment is not far from the white line. It's right next to it.

I just explained why it's wrong. Can't we accept it and move one instead of bringing up arbitrary stuff.

As I said, the bullet’s deceleration doesn’t matter. If there’s no way to determine how far the bullet actually traveled, the distance found by the calculation can be used. Because if the bullet moved in the panel where it was cut, the distance calculated will be larger than the distance the bullet actually traveled. That means the result will come out lower than it should. Therefore, the calculation can still be used.

I'll just wait for calc group to evaluate it since you don't understand my debunks, which is okay.

 

[Viott]

Viott bro, this is NOT how that works.

If the bullet is supposed to go this far ———
but it went this far —————————————————
Then the distance moved is larger making the end speed of the character slower. Because Speed = distance / time.

The exact opposite, this is how things work. If there is no way to determine the actual distance the bullet traveled, the distance I calculated can be used. Because the result comes out lower than it should.

I just explained why it's wrong. Can't we accept it and move one instead of bringing up arbitrary stuff.

As I said, the bullet is not away from the white line; it is next to it.

I'll just wait for calc group to evaluate it since you don't understand my debunks, which is okay.

You haven’t debunked anything. And I understood your arguments very well. But you didn’t understand my debunks.

Also, this CRT exists only to update profiles. So don’t divert the topic.

 

[Dinozxd]

Also, this CRT exists only to update profiles. So don’t divert the topic.

Not gonna comment on other stuff cuz I don't like 2v1 debates very much, but this isn't how CRTs work. You're using the calculation in the CRT so ofc the accuracy of the calculation can also be questioned.

 

[Viott]

Not gonna comment on other stuff cuz I don't like 2v1 debates very much, but this isn't how CRTs work. You're using the calculation in the CRT so ofc the accuracy of the calculation can also be questioned.

Issues with calculations are for the calculation group discussions. This CRT is only for applying the accepted calculation.

 

[DivineAura44]

Issues with calculations are for the calculation group discussions. This CRT is only for applying the accepted calculation.

Nope. Calculations can be disputed in the CRT.

PS: Instead of saying "Gapryong is a legend" just say he's top 1 in the verse. Much quicker and it's quantifiable.

 

[Viott]

Nope. Calculations can be disputed in the CRT.

That’s what CGD is for. That’s why I don’t agree.

PS: Instead of saying "Gapryong is a legend" just say he's top 1 in the verse. Much quicker and it's quantifiable.

It is enough for me to write “He is a legend of the 0th Generation.

 

[DivineAura44]

That’s what CGD is for. That’s why I don’t agree.

Please tell me where it says you have to dispute the calc in CGD? Because to my knowledge...
"Before making sweeping or significant changes to characters or verse pages, please start a thread in the Content Revision forum first, so that the suggestions may be evaluated by our Staff and the community at large, to ensure that they are acceptable. The concluding evaluations must be handled by Thread Moderators, Administrators, or Bureaucrats, who should make an effort to base their evaluations on valid arguments, not personal opinions."
And someone is currently evaluating that one of your accepted calcs isn't acceptable.

 

[Viott]

Please tell me where it says you have to dispute the calc in CGD? Because to my knowledge...
"Before making sweeping or significant changes to characters or verse pages, please start a thread in the Content Revision forum first, so that the suggestions may be evaluated by our Staff and the community at large, to ensure that they are acceptable. The concluding evaluations must be handled by Thread Moderators, Administrators, or Bureaucrats, who should make an effort to base their evaluations on valid arguments, not personal opinions."
And someone is currently evaluating that one of your accepted calcs isn't acceptable.

Anyway, I won’t drag this topic out any further. Even if calculations are discussed in the CRT, it won’t be a problem for me.

 

[Viott]

Bump

 

[Pxnd_013]

I think Samdak, Ryuhei, No.1 should also be upgraded.

 

[GrathOfLux]

I'm not qualified to evaluate calculations, though I at least think the matter here has been established enough to cast some doubt on the variables used. I would like to have a calculation group member look at this thread before proceeding.

 

[Second22]

I get what Vzearr’s saying tho. Like, in the second panel it looks more like the dude moved after the bullet got cut. And if you’re gonna interpret it that way, then why not calc the guy raising his hand to block the shot too? Doesn’t make sense, right? Cuz if he was really faster than the bullet like that, he would’ve just dodged from the start. The whole face-turn distance thing just throws the scaling off for real.

I think there’s a simple fix here - no need to overcomplicate it by calcing the distance from the PoV to the bullet or anything like that. Just use

the distance between the face and the bullet: 982.7 px | 0.1365195338 m

from the first panel, that’s already enough. You could even take that as the slash distance by working with the px from the first image. So can’t really say this feat is “debunked” - it’s still a solid, clear feat that works perfectly fine for a calc, it just needs to be corrected properly.

 

[Second22]

1) In the calculation, I’m finding Manager Kim’s speed, not Seongho Shin’s. The fact that Seongho Shin doesn’t dodge the bullet doesn’t change the reality that we can find a distance close to the actual distance the bullet traveled. These are two different matters.

The whole issue isn’t even the “real distance” you used, cuz in that panel Shin’s already moved his head. The actual distance between his face and the bullet should’ve been way smaller. And if you go off that, the calc speed drops a lot.

2) Since he turned his head, the distance between the bullet and his face decreases slightly, which means that the distance I found is a bit greater than the distance the bullet actually traveled. If there is no way to determine the actual distance the bullet traveled, the distance I calculated can be used. It’s a bit more, but better than nothing.

Nobody really knows if he just turned his head or leaned his whole body back too. But like, human nature? Of course he’d lean back to dodge. It might look like a small detail, but the result could end up way higher than what actually makes sense. Like, say the character just leans back a bit + turns his head, only around 10 cm - that’s a tiny, reasonable distance. But the calc would drop to like 364.85 m/s, which is way lower than before. So nah, you definitely can’t just brush it off as a “bit more.”

That distance can't be used because the bullet doesn't reach the character's face. As I said, a distance close to the actual distance the bullet traveled can be found.

It’s the safe distance.

 

[Viott]

Oops, I accidentally deleted my message.

The whole issue isn’t even the “real distance” you used, cuz in that panel Shin’s already moved his head. The actual distance between his face and the bullet should’ve been way smaller. And if you go off that, the calc speed drops a lot.

If there is no way to find the actual distance the bullet traveled, the distance I calculated can be used.

Nobody really knows if he just turned his head or leaned his whole body back too. But like, human nature? Of course he’d lean back to dodge. It might look like a small detail, but the result could end up way higher than what actually makes sense. Like, say the character just leans back a bit + turns his head, only around 10 cm - that’s a tiny, reasonable distance. But the calc would drop to like 364.85 m/s, which is way lower than before. So nah, you definitely can’t just brush it off as a “bit more.”

There is no evidence that he leaned his entire body backward. You are making that up.

It’s the safe distance.

For the reasons I explained, the distance I calculated can be used.

 

[Second22]

If there is no way to find the actual distance the bullet traveled, the distance I calculated can be used.

Just stick with the distance from his face in the first panel, that’s the safest and most reliable take.

There is no evidence that he leaned his entire body backward. You are making that up.

Yeah, but c’mon, you can’t say he didn’t lean, the panel’s too vague for that. That “safe distance” stuff? Kinda shaky. Even just a tiny lean plus the head turn messes up the calc big time. And let’s be real, dude literally turns his head anyway, so your number still ain’t the real deal.

For the reasons I explained, the distance I calculated can be used.

dude...

 

[Viott]

Just stick with the distance from his face in the first panel, that’s the safest and most reliable take.

I’ve already explained this.

Since he turned his head, the distance between the bullet and his face decreases slightly, which means that the distance I found is a bit greater than the distance the bullet actually traveled. If there is no way to determine the actual distance the bullet traveled, the distance I calculated can be used. It’s a bit more, but better than nothing.

Yeah, but c’mon, you can’t say he didn’t lean, the panel’s too vague for that. That “safe distance” stuff? Kinda shaky. Even just a tiny lean plus the head turn messes up the calc big time. And let’s be real, dude literally turns his head anyway, so your number still ain’t the real deal.

You’re claiming this, but you have no evidence.

 

[Second22]

You’re claiming this, but you have no evidence.

And let’s be real, dude literally turns his head anyway

 

[Viott]

I’ve already explained this.

Since he turned his head, the distance between the bullet and his face decreases slightly, which means that the distance I found is a bit greater than the distance the bullet actually traveled. If there is no way to determine the actual distance the bullet traveled, the distance I calculated can be used. It’s a bit more, but better than nothing.

 

[Second22]

I’ve already explained this.

It’s not a “bit greater”. I already explained facing direction matters a lot for the calculation. He didn’t just move like 1 mm or something, it was way more than that. We don’t even have enough proof of how much he moved, so we shouldn’t use it at all.

 

[Viott]

It’s not a “bit greater”. I already explained facing direction matters a lot for the calculation. He didn’t just move like 1 mm or something, it was way more than that. We don’t even have enough proof of how much he moved, so we shouldn’t use it at all.

No, the bullet travels a slightly shorter distance than the distance I calculated, because the distance between the bullet and the face decreases slightly due to him turning his head.

 

[Dinozxd]

It’s the safe distance.

I literally brought this same point up multiple times in a different thread but was accused of "downplaying Lookism", which is like the most common form of ad hominem you can see on this site.

I agree with Second's claim.

So can’t really say this feat is “debunked” - it’s still a solid, clear feat that works perfectly fine for a calc, it just needs to be corrected properly.

(Defending my twin) He didn't really claim that he debunked the feat though, he said that he debunked the calculation. To put into perspective, debunking the feat would be more like "This feat can't be used because MK actually moved before the bullet was fired!" while debunking the calc would just be debunking the distance used, which is what he did.

 

[Viott]

I literally brought this same point up multiple times in a different thread but was accused of "downplaying Lookism", which is like the most common form of ad hominem you can see on this site.

Do you want to read my other comments in that thread? I’ve explained multiple times why the distance I calculated is safe. But you kept saying the same things without understanding my argument.

 

[Dinozxd]

Do you want to read my other comments in that thread? I’ve explained multiple times why the distance I calculated is safe. But you kept saying the same things without understanding my argument.

I did read your other comments in that thread.

No. I never kept saying the same things without understanding your arguments. In fact you're doing the exact same thing in this thread.

 

[Viott]

No. I never kept saying the same things without understanding your arguments.

You were repeating arguments that I had already debunked.

In fact you're doing the exact same thing in this thread.

If the arguments I’ve already debunked are repeated, I’m forced to explain the same thing again.

 

[Dinozxd]

You were repeating arguments that I had already debunked.

If the arguments I’ve already debunked are repeated, I’m forced to explain the same thing again.

Yeah this will just turn into a "No u" type of argument that will lead nowhere. I share @Second22 's views on the topic of the distance used, but that's kinda irrelevant rn cuz of the remaining part of my reply.

While looking at your calc in more detail again, It seems like you used the case diameter of the bullet (11.35 mm), instead of the diameter of the bullet itself. The diameter of the bullet is 7.62 mm (it's literally in the name lol). You also pixel scaled the bullet's length, which is... weird? The bullet's name literally includes it's length too (39 mm), not whatever length you found. Now, applying these changes to your calc would change the pixel scaled distances quite a bit:

Spoiler: New "distances"

Here's the calc.
First Scan
The diameter of the base: 0.00762 m | 81.7 px
the length of the bullet: 0.039 m
The distance between the face and the bullet: 982.7 px | 0.09165451273 m

Fourth Scan (Just to get it outta the way)
The diameter of the base: 0.00762 m | 222.2 px
The minimum distance traveled to cut the bullet: 1159.8 px | 0.03977350851 m

Third Scan (Now this is where it gets funny)
Distance PoV to Face: (0.1601673717*2612.3)/[1145.6*2tan(70/2 deg)] = 0.2607998377 m (Unchanged)
Distance PoV to bullet: (0.00762*2612.3)/[222.2*2tan(70/2 deg)] = 0.06397012355 m
Bullet to face: 0.2607998377 - 0.06397012355 = 0.19682971415 m
Bullet length = 0.039 m
The distance between the face and the bullet: 0.19682971415 - 0.039 = 0.15782971415 m
Distance traveled by the bullet: 0.09165451273-0.15782971415 = - 0.06617520142 m ?????

Oh damn. MK seems to have traveled negative distance. Doesn't that give him Immeasurable speed tho?

I don't think I have to outright tell you why this invalidates the method used on the calc. This also invalidates the use of the bullet diameter as a reference for the pixel scale (only in the first scan), as the bullet dimensions highly contradict each other. Going from your pixel values, using the bullet diameter as a reference gets me about 30 mm for the bullet length, which is a 9 mm difference compared to it's actual length. Likewise, using the bullet length (39 mm) as a reference for the diameter gets me the incorrect dimension as well. You already found his face height. Just use that as a reference in the first scan, but remove his teeth height. Assuming that the bullet travels 10 cm, the result should comfortably be in the Subsonic+ range.

 

[Viott]

I don't think I have to outright tell you why this invalidates the method used on the calc. This also invalidates the use of the bullet diameter as a reference for the pixel scale (only in the first scan), as the bullet dimensions highly contradict each other. Going from your pixel values, using the bullet diameter as a reference gets me about 30 mm for the bullet length, which is a 9 mm difference compared to it's actual length. Likewise, using the bullet length (39 mm) as a reference for the diameter gets me the incorrect dimension as well. You already found his face height. Just use that as a reference in the first scan, but remove his teeth height. Assuming that the bullet travels 10 cm, the result should comfortably be in the Subsonic+ range.

I hadn’t realized that I used the wrong base of the bullet. Since it was inconsistent, another reference point can be used.



0.039 m | 324.6

1100.3 px | 0.1321987344 m



1.82 m | 3154.4 px

37 px | 0.0213479566 m



(0.0213479566*2612.3)/[197.1*2tan(70/2 deg)] = 0.2020393487 m

(0.00762*2612.3)/[222.2*2tan(70/2 deg)] = 0.0639701236 m

0.2020393487 - 0.0639701236 - 0.039 = 0.0990692251 m

0.1321987344 - 0.0990692251 = 0.0331295093 m

 

[Dinozxd]

0.039 m | 324.6

This also invalidates the use of the bullet diameter as a reference for the pixel scale (only in the first scan), as the bullet dimensions highly contradict each other. Going from your pixel values, using the bullet diameter as a reference gets me about 30 mm for the bullet length, which is a 9 mm difference compared to it's actual length. Likewise, using the bullet length (39 mm) as a reference for the diameter gets me the incorrect dimension as well.

Maybe I didn't state it clear enough but using the bullet length in the first scan is also inconsistent with the bullet diameter so it can't be used either.

37 px | 0.0213479566 m

Using eye length (?) is also problematic as it's a small reference. Small references give incorrect angsizing results. Plus his eyes are at normal length in the full body scan, while they're wide open in the third scan.

 

[Viott]

Maybe I didn't state it clear enough but using the bullet length in the first scan is also inconsistent with the bullet diameter so it can't be used either.

Upon rechecking, I realized that 39 mm is the case length, not the bullet length. Therefore, by using the bullet’s base diameter as a reference, the bullet’s length can be determined. That’s why I don’t agree with you.

Using eye length (?) is also problematic as it's a small reference. Small references give incorrect angsizing results.

This is not always valid. Since the result is consistent, it can be used.

Plus his eyes are at normal length in the full body scan, while they're wide open in the third scan.

Opening the eye completely does not change its length.

 

[Viott]

I'm recalculating because I used 39 mm.




0.00762 m | 81.7 px

324.6 px | 0.0302748253 m

1100.3 px | 0.1026228904 m



(0.0213479566*2612.3)/[197.1*2tan(70/2 deg)] = 0.2020393487 m

(0.00762*2612.3)/[187.6*2tan(70/2 deg)] = 0.0757684513 m

0.2020393487 - 0.0757684513 - 0.0302748253 = 0.0959960721 m

0.1026228904 - 0.0959960721 = 0.0066268183 m

 

[Dinozxd]

Upon rechecking, I realized that 39 mm is the case length, not the bullet length.

That's true. Mb.

This is not always valid. Since the result is consistent, it can be used.

You're telling me that the dude's face is 6 cm away from the dude's eyes and also telling me that's consistent. Nah. His face is visible. That means you angsize his face, not a part of his face that matches your desired distance. That's called a fake pixel scale.

Opening the eye completely does not change its length.

I mixed it up with eye height ig. Though the panel you used to calculate his eye width (length is an incorrect term i think) is tilted to the side and down a bit, which makes his eye width look smaller than normal, same with his face height.

Using his eye width is incorrect either way (the reason for that will be explained below). If i can convince you (smh) into using face height, you should use the human propotions calculator for that as that full body length panel won't give you accurate results, for the reasons i explained above.

0.00762 m | 81.7 px

324.6 px | 0.0302748253 m

1100.3 px | 0.1026228904 m

Again, this is just stupid. You have a much larger reference fully visible in the panel but you're using a 7mm object to pixel scale the distance. It's been widely agreed by CGMs that using a decently large object by both pixels and irl size gives you the most accurate reference for a pixel scale. I know that sometimes you gotta use a small reference. I've done that too, but that doesn't mean it's a choice based thing. You do that when you don't have anything elss to pixel scale or angsize from.

Shortly, you're not forced to use the bullet length or diameter here. There's a big ahh face on the panel. You have to use that for the most accurate result.

 

[Viott]

You're telling me that the dude's face is 6 cm away from the dude's eyes and also telling me that's consistent. Nah. His face is visible. That means you angsize his face, not a part of his face that matches your desired distance. That's called a fake pixel scale.

Because when we use face height as a reference, the distance comes out greater in the second panel, which gives an inconsistent result. But when we use eye width as a reference, the result comes out more consistent.

I mixed it up with eye height ig. Though the panel you used to calculate his eye width (length is an incorrect term i think) is tilted to the side and down a bit, which makes his eye width look smaller than normal, same with his face height.

When I use a better panel, the width of the eye doesn’t change much.

If i can convince you (smh) into using face height, you should use the human propotions calculator for that as that full body length panel won't give you accurate results, for the reasons i explained above.

There’s no need for this. We can find the eye length from a better panel.

Again, this is just stupid. You have a much larger reference fully visible in the panel but you're using a 7mm object to pixel scale the distance. It's been widely agreed by CGMs that using a decently large object by both pixels and irl size gives you the most accurate reference for a pixel scale. I know that sometimes you gotta use a small reference. I've done that too, but that doesn't mean it's a choice based thing. You do that when you don't have anything elss to pixel scale or angsize from.

Shortly, you're not forced to use the bullet length or diameter here. There's a big ahh face on the panel. You have to use that for the most accurate result.

The same doesn’t apply here. The base diameter of the bullet is precisely known. If we take face height as a reference, the base diameter of the bullet would change, so it’s not reliable.

 

[Dinozxd]

Because when we use face height as a reference, the distance comes out greater in the second panel, which gives an inconsistent result.

It just means that your method is inconsistent, not the panel.

But when we use eye width as a reference, the result comes out more consistent.

I think you meant "comes out more consistent to my liking" because angsizing the eye width completely contradicts the angsizing to the face. The face reference holds a priority because it's a bigger reference. Angsizing gives weird results on small references, same as regular pixel scaling.

There’s no need for this. We can find the eye length from a better panel.

Well my main point isn't about finding the better eye length, it's not using the eye length at all so whatever.

The same doesn’t apply here. The base diameter of the bullet is precisely known. If we take face height as a reference, the base diameter of the bullet would change, so it’s not reliable.

It changes because it's a small reference. Artist don't really care about small references so they don't draw them with as much detail and consistency as bigger references. That's why the bullet's diameter changes. Literally do the opposite and the diameter of the bullet would contradict the guy's face height instead.

Note: This version of the calc literally proves my point on this, using the diameter as the reference gets me about 14 cm for the dude's face. How is it possible for a 1.85 meters dude to have a face height shorter than a teenage girl who's 1.4 meters tall (according to this)?

The face height takes priority over the bullet anyways due to being the larger reference, like I've been saying.

 

[Viott]

It just means that your method is inconsistent, not the panel.

Since the result is inconsistent in the angsize formula, I use the eye length.

I think you meant "comes out more consistent to my liking" because angsizing the eye width completely contradicts the angsizing to the face. The face reference holds a priority because it's a bigger reference. Angsizing gives weird results on small references, same as regular pixel scaling.

This is only valid when you use the eye as a reference to measure something. It does not apply to angsize. Also, since the eye is close to the screen, the result will not be inconsistent.

Well my main point isn't about finding the better eye length, it's not using the eye length at all so whatever.

I’m aware. I’m already explaining to you why you’re mistaken.

It changes because it's a small reference. Artist don't really care about small references so they don't draw them with as much detail and consistency as bigger references. That's why the bullet's diameter changes. Literally do the opposite and the diameter of the bullet would contradict the guy's face height instead.

Note: This version of the calc literally proves my point on this, using the diameter as the reference gets me about 14 cm for the dude's face. How is it possible for a 1.85 meters dude to have a face height shorter than a teenage girl who's 1.4 meters tall (according to this)?

The face height takes priority over the bullet anyways due to being the larger reference, like I've been saying.

When I check this myself, I find the height of the face to be 0.1584438483 m.




When I use the height as a reference, I find the face height to be 0.1585794247 m.



Since it is quite consistent, using the base diameter of the bullet as a reference will not cause any problem.

 

[Dinozxd]

Since the result is inconsistent in the angsize formula, I use the eye length.

This is only valid when you use the eye as a reference to measure something. It does not apply to angsize. Also, since the eye is close to the screen, the result will not be inconsistent.

It still doesn't change the fact that the angsizing to eye is inconsistent with the angsizing to the face. Your angsizing to the eye is what's inconsistent.

Angsizing is also a form of pixel scaling, as you literally use pixels to angsize stuf. What applies to pixel scaling also applies to angsizing. Also, I love how you literally proved my other point about using the face height rather than the bullet diameter in the bolded part. Yes, you don't use eye length to pixel scale distances because it's a small reference and with the same logic, you should be able to figure out which reference to use in the first scan. Larger reference (face height), or the smaller reference (bullet diameter).

When I check this myself, I find the height of the face to be 0.1584438483 m.

Just to be clear btw, I was completely wrong here:

Literally do the opposite and the diameter of the bullet would contradict the guy's face height instead.

Note: This version of the calc literally proves my point on this, using the diameter as the reference gets me about 14 cm for the dude's face. How is it possible for a 1.85 meters dude to have a face height shorter than a teenage girl who's 1.4 meters tall (according to this)?

Doing the opposite would get you the exact same distance. Idk what I was thinking when I typed this out. The rest of that part of the reply is true though.

I did my own pixel scaling on it btw (also excluding the teeth as that's not a part of his face) and got 13.9 cm, but again, this height isn't reliable as it comes from a small reference rather than the character's full height or the human proportions calculator. I also don't buy that a dude who's between 1.80 and 1.85 meters to have a face shorter than 20 cm, at the very least (the human proportions calculator also sides with me on this one btw) because a face height of 13.9 cm would mean that this dude is about 1.20m, which also means that he's biologically suffering from dwarfism.

I understand that the hpc can't always be taken as absolute but this much difference isn't logical, straight up.

When I use the height as a reference, I find the face height to be 0.1585794247 m.

I again, made my own pixel scale here and although I got a bigger number than you, it doesn't really matter as it's not a big difference so whatever.

Looking at the panel more though, this dude seems to have his face tilted to the side and forward a bit. That's supported by the fact that his shoulders are high (same with the other full body panel you sent).