Chess, Pencil Art, Piano, Composing, Playing Games, Programming Games, Acting on Japanese TV/Movies, Authoring, Designing Games, Martial Arts, LEGO® Technic™, 3D Modeling, Japan, Tokyo, ภาษาไทย, 日本語, le français
I don’t even agree with the basic premise. Why can’t you master all? Exactly what preventative barrier exists?
These obnoxious little slogans such as, “Make games, not engines,” and, “Jack of all, master of none,” put us into a mindset that causes these little catch-phrases to be true.
If I want to be a programmer, does that mean I have to not be an artist? My avatar is a pencil-and-paper drawing, details in my signature.
I also make my own music (details in signature). After I skipped 4 years in science in school I decided to write my own physics engine, which lead me to create a graphics engine so that I could see the physics in motion, which lead me to being a senior graphics programmer at Square Enix on Final Fantasy XV, but my passion was always in AI, so after graduating from Stanford’s AI course I am currently focusing on AI in my career.
Could you imagine if I had said, before all of these academic ventures, “I am interested in a lot of things, so I should just dip into it and not get too deep”?
Yes, then I would just be a jack of all and a master of none. What a pathetic self-defeating attitude to life.
Get out there and leave your footprint. This world is not for testing, it is for mastering. There is literally nothing stopping you except some kind of self-defeating attitude that tells you that you have to either master one, or basically explore all. No. You do all, you master all. No excuses.
Lecture your teacher on how these are not used in the industry (see many posts above), and for very good and obvious reasons.
Within such a modular grouping of code, logical connections between related code need not have diagrams for them to be clear to the people who matter.
Trying to use UML to explain the entirety of an engine or game is note only a waste of resources but counter-productive as it is nothing more than clutter in a programmer’s already-scrambled brain. If I am working on AI, why do I need to know the entire class hierarchy of the entire game, including the UI, renderer, etc.? If I need knowledge on parts of another system, talking to people directly is most effective, and in-house Wiki’s (the standard in the industry) are more maintainable.
A scoped UML diagram is pointless since people not-only don’t think that way but programmers tend to know their own scope anyway.
A non-scoped UML diagram of an entire project causes detail to get lost in the clutter and serves only to overwhelm everyone.
In either case, it takes time and resources to keep these up-to-date and representative of the actual code-base.
UML promotes a strict unchanging design that is incapable of adapting to new needs as they arise for 2 reasons:
#1: They make it a pain in the ass to implement any changes, since time has to be added to update the UML diagrams.
#2: One of the ideas behind UML is to design first and then code, which is an approach that implicitly lends itself to a set course that is hard to change.
Not only that, but my biggest gripe is that UML uses wrong symbols. According to UML, an empty arrow from one class indicates that that class inherits from the class to which the arrow points. This is wrong.
Diagram <------ ModelDiagram
UML says that ModelDiagram inherits from Diagram. But the arrow points the wrong way. According to the arrow, “ModelDiagram goes into Diagram,” when in fact it is the opposite—ModelDiagram comes from Diagram.
Diagram ------> ModelDiagram
This is how UML should look.
We have tried this in my first company and we dropped it for a reason. It doesn’t work, it doesn’t easily convey what it is meant to convey, it is hard to scope properly, and it is easy to abuse into a cluttered mess. It takes man-hours and costs companies money.
But if you have to do it, I have no suggestions. Just know how futile it is.
If you are running the same points through the same modification you will get the same results. This means your normals are slightly off between similar vertices. Fix this before starting to use indices. You wouldn’t be able to generate indices anyway if the vertices are slightly off anyway, and even if you did then you would just be masking the problem, not solving it.
Re-examine your method for calculating points, specifically in how to generate discrete normals for same points.
Don’t ignore it. Ignoring obvious problems leads to at least half of the performance problems we have today.
Either move the origin of the octree as mentioned above or use a better method for the vertical component of the tree. Octrees are typically not used due to memory constraints and because they are a poor match for the landscapes in most games (hence the problem you are having).
What is typically implemented is a quadtree for the X and Z planes and a stack of flat boxes for the Y (vertical). Dividing the world into vertical slices fits better with actual in-game landscapes and requires very little memory.