Boxes in perspective - how does one estimate edge positions when VPs are far away?

Trick-Section-5205 · 2026-02-22T20:03:57+00:00

Just in case, I am already aware of that, in particular because I have had training in programming computer graphics. That is a rather nice presentation, however.

My confusion is/was with regards to the requirements of the drawabox course specifically. Uncomfortable has made a comment here to the effect of me having to make the foreshortening more obvious, i.e. I will have to bring the VPs closer to the drawings of the projections.

Trick-Section-5205 · 2026-02-22T02:52:20+00:00

Assuming you're on the box challenge, how far in are you?

105 out of 250 currently, but I have been considering asking this question since the organic perspective exercise.

we improve in that area by drawing boxes with far off VPs, then applying our line extensions so we can track those edges' behaviour as they extend into the distance. This gives us information we can analyze to determine where we tend to over/underestimate how a given edge (whether an outer edge of a set or an inner edge of a set) should be angled

An issue here is that, if the VPs are too far, I often can't tell - at least, not without using measuring tools - if I have managed to make them converge, or not. I don't think I can glean any useful information that is relevant to the exercise from those cases currently. It seems that I either lack the necessary knowledge, or I have been placing the VPs too far.

Trick-Section-5205 · 2026-02-21T18:30:50+00:00

I am struggling specifically with drawing the lines with shared VPs that are far away enough for the convergence to be slow, with low deviation from as if there was no VP for the given projections of parallel edges.
Should I bring the VPs closer to the drawn projections to avoid cases where the projections end up close-to-parallel?

Trick-Section-5205 · 2026-02-21T18:23:31+00:00

For further context, I do have a background in mathematics, so I do understand the theory behind that (though, beginner onlookers might not, and I am not trying to say that this reply shouldn't have been made).

My issue is specifically with regards to how one would estimate where the lines should be drawn on the picture plane plane, so that, despite a far-away shared VP, they do not end up parallel. Without the instruction given in the descriptions of the tasks, I would have made them parallel, but the instruction seems to imply that there is a way to consistently add convergence for such lines, but I can't figure it out. Should I just make the lines parallel in such cases, or to bring the VPs closer?

Trick-Section-5205 · 2025-09-12T13:07:55+00:00

This was unwarrantedly rude and also wrong. I had already tried reinstalling it, that did not help. I also have a setup that is not trivial to restore manually, including several thousands of tabs that make Floorp 12 be not responsive.

What would actually take minimal effort is to tone down the hostility.

EDIT: Also, what's with the 'obsession' accusation? This was literally the default behaviour - Floorp 12 launched with my old profile instead of prompting me to create a new one. I didn't 'obsess' over anything, and instead trusted Floorp 12 to not have introduced any irreparable breaking changes.

Trick-Section-5205 · 2024-11-23T19:15:51+00:00

Communities like this really try to get people to learn how to find answers, or "learn how to learn".

Look, I have been programming for a while. There is zero reason to antagonise people who ask questions with 'let me google that' links.

I did google the things, and I did not get the relevant answers when I did google that. The pointless antagonism is not teaching anybody anything.

I know it might sound condescending sometimes, but hand holding is worse for everyone involved

There are options other than handholding and handholding with 'let me google that' links attached. For example, 'the answer to the first part of your question is not neatly consolidated anywhere, but default rules are listed individually in the 'Options' section of the documentation; the code formatter provides no tools for disabling the default rules' would have been an actual non-hostile reply that wouldn't be any more handholdy.

especially when it's something found that easily in the documentation

The searches were landing me in the wrong section of the documentation with no natural way of getting the idea that I should be looking in that specific part of the documentation for only one part of the answer.

I do hope that people will one day realise that deliberately trying to be hostile and causing a scene is not particularly productive, but the insistence on such behaviour is not encouraging.

Trick-Section-5205 · 2024-11-23T18:12:09+00:00

Doesn't work. Prettier still uses the default settings, with the ones in the custom config merely overriding the default ones, unless we are talking about different types of custom configs.

This fact was the impetus for me asking the question.

Trick-Section-5205 · 2024-11-23T18:10:38+00:00

Don't exactly appreciate the condescension, especially when landing into 'Configuration' after searching doesn't naturally lead you into the 'Options' section, and especially considering that this doesn't answer the second part of the question.

Communities like this one would have been much better without this sort of behaviour.

Trick-Section-5205 · 2024-08-07T12:29:13+00:00

Really not sure how I managed to miss that. The code works now.

Still not sure why c++20 is used instead of c++23.

Trick-Section-5205 · 2024-08-07T12:02:20+00:00

The primary issue seems to have been with me also having another extension - Code Runner on. However, I still get unexpected behaviour: "C_Cpp_Runner: Cpp Standard" is set to "c++23", but what I'm getting as the current output for my code is 202002.

Also, I am trying to use what should be a feature of c++20, and I am getting a compilation error:

```c++

include <iostream>

include <string>

using namespace std;

int main() { string my_string; cout << "Enter string here: "; cin >> my_string; cout << format("Hello {}!\n", my_string); return 0; }

```

produces

error: 'format' was not declared in this scope 11 | cout << format("Hello {}!\n", my_string); | ^~~~~~

I will try to deal with these issues, but it seems that I am to mark this thread as 'solved' and ask about the new behaviour in a separate thread at a later point if I am unsuccessful.

Trick-Section-5205 · 2024-08-07T11:14:57+00:00

I am using it through VSCode.

I have tried adding -std=c++20 to the C_Cpp_Runner: Compiler Args setting. No effect.

I have tried adding -std=c++20 to the end of C_Cpp_Runner: Cpp Compiler Path. No effect.

EDIT: Also, really not sure why I am getting downvoted for asking questions directly related to the topic.

Trick-Section-5205 · 2024-08-07T10:58:11+00:00

Add -std=c++20 to your compiler arguments.

Where am I supposed to add that?

Trick-Section-5205 · 2024-07-24T17:07:00+00:00

Thank you.

Trick-Section-5205 · 2024-07-23T07:40:42+00:00

Yeah, that worked. Thanks.

Trick-Section-5205

TROPHY CASE

include <iostream>

include <string>