Which is easier on you and also makes it easier to change the container type.
Which raises the question: Why are you using a list rather than a vector? vector is superior in the overwhelming majority of cases, most especially for iteration, which I see you doing plenty of here.
Also, I mentioned DRY and switches in your other thread. You've got some of that going on here. You're doing the same thing in both cases, but with different containers. Why not make that process a function:
void doStuff(std::list<Vertex>& container);
and then just
case 1: doStuff(vertices); break;
case 2: doStuff(rotated); break;
You can also take advantage of the new for-each syntax, except in the case where you're using the 'previous' iterator (though you could just retain a pointer to the element there):
Therefore avoid it when you can reasonably do so. Depending on the situation there's a decent chance that the nested switches could be within function calls, which is easier to read and probably supports DRY in many cases.
I have no idea why std::endl would behave in this way
Because endl is a turd that only causes problems. You don't need to flush the stream at that point either (whoops! endl does that too) because all it will do is harm performance. Just use your LINE_END instead or just use L"\n", which is less typing.
You really need your coordinate systems to share the same origin if they're supposed to correspond. The typical solution to this is to employ an offset, which can be metadata with your model (just marking the position of the barycenter/CoM in model space) or you can calculate it at load time if it's just barycenter. It would be easier in the short-run to center the pivot, but if that's restrictive for you then building that offset system is a one-shot solution that will remove the restriction and let you do your thing (not counting bugs, etc).
The basic idea is to transform the CoM along with the object and then use the resulting position as the offset for aligning the spaces.
For example, in the picture you showed we can say that the bottom-center of the model is at 0,0,0 and the barycenter is at 0,1,0. So just add 0,1,0 to to the object position for bullet and the AABB should align correctly.
Okay, so you know about debuggers already. Fantastic. Let me just make sure that we're on the same page here.
You've already got bullet debug view on - so clearly we're not talking about that. Let's cross that off the list.
You didn't post shader code because it sure doesn't seem like a shader issue, so digging up pix from the depths of history probably isn't what we're after. Let's go ahead and cross that off the list too.
You did post application code, because that's where the issue probably is.
The code you posted is relatively short and not very complex.
Your issue is an IPO (input-process-output) problem where the process is the prime suspect.
So of our remaining option, what tool can generally identify and isolate that kind of problem in about 30 seconds?
When you first start out the important thing is to get your feet under you. If you can do small projects comfortably in SFML then you're on the right track. The danger is in using alternatives as a means of running away from things you don't understand. Ideally you want to reach a point where you feel good about the language you're using and then take up another language just to see what it is and what you can do with it. If you fall into the habit of running away any time you find a difficult problem then you're only going to become incompetent in many different languages. Beat the problems to get stronger and branch out from that position of strength.
Incidentally, there are a lot of people who can't do what you've done so far, so keep going.
Simple setters are generally pointless. If outside logic should be able to directly set an object's members, those members should generally be public,
The guidelines are actually opposed to both (avoid trivial get/set and avoid public class members), which is a bit of a sore point for me, but even the discussion around the guidelines was peppered with people saying, "It's a guideline, not a rule."
Honestly, it's nice to have a super well-formed system, but you can spend years on every trivial item and still have issues. I think it's really down to experience and learning what things save time in the long run and what things don't, and what's true for you and yours may not be the same for other people.