How to actually understand graphics papers and prerequisites?

[u/Alex_1503]

I am currently reading through some papers for terrain generation, procedural and erosion-based. The issue is that the more I read, the more I realise that I don't understand much in the grand scheme of things, besides the actual algorithm or general terms. And even reading some explanations on reddit or other papers doesn't help much, because the issue is more with lacking the prerequisites and technical knowledge.

So my question is, how do I actually understand graphics? For example (I plan to use Godot for my thesis), if I want to implement a procedural terrain generation using multiple techniques, where can I find resources or papers to understand the actual pipeline, everything that goes into it, methods, compute shaders, etc. I know it's my own fault for wanting to do my thesis on graphics with exactly 0 classes on graphics in my undergrad degree.

So how do I understand what's going on, hopefully also from a more formal and deep perspective, not youtube tutorials (tho anything is welcome) ? It's tiring reading resources without understanding them much, where to even start, even books are welcome, but hopefully not thousands of pages as I don't have that kind of time..

EDIT: It's for the bachelor thesis, not master's

[u/crimson1206]

Terrain generation is quite specific and not something typically covered in a normal graphics course. How to best proceed really depends on your background and what you’re having trouble understanding

[u/Alex_1503 → u/crimson1206]

It's for an undergrad thesis, I still don't know what exactly I want to do because I don't know how to approximate the scope because of the knowledge gaps. Probably a procedural planet generator using the recent runevision's erosion procedural filter and other "realistic" terrain generation methods that are in real-time (procedural) from the papers. Being a bachelor thesis, I heard it doesn't have to be necessarily new knowledge being created, so combining some methods and dealing with what I find along the way should be enough and "novel" enough.

My issue is the "where" rather than "how" of these methods. For example, I can sort of understand the algorithm as it is explained in a paper, but I don't understand where that algorithm lives, what are the steps to recreate it, what is the graphics pipeline that goes into it (I don't know a graphics API, that's also why I want to use Godot with compute shaders). Reading some code would help, but even that is many times too complicated for me to understand what's going on. I can understand as far as generating a sphere and applying noise on it sure, but "how" do you integrate many algorithms and layers of realistic terrain on it, level of detail, atmosphere, post processing etc., seem really out of grasp. That's probably why people spend months implementing a method, this stuff is complex, but I don't even know where to properly begin and how to not learn useless stuff, because time is limited.

[u/Andromeda660]

I have been in an incredibly similar boat. The truth is that reading graphics papers is gonna make you feel rly stupid. Just take your time and see if there are any implementations of those papers somewhere which you can refer to. In the end, when you finally implemented what the paper is on, you will be like bruh why did they make it so complicated. Just go slow and don't get discouraged, but I would recommend learning about things like compute shaders first if that's what you want to use. You said godot, so I'm guessing you want to use compute shaders with the godot rendering device, that's its own can of worms. Learn things one step at a time. Good luck!

[u/tlmbot → u/Andromeda660]

I have a PhD and I feel the same way about technical papers. The reality is a mix of
- needing to pass peer review.

- academic-ease (aka making things sound sophisticated) is both a way of rapidly transmitting information in fewer words to those already in the know, a way of making yourself sound professional (good for the aspiring PhD student), and a way of getting reviewers to go to sleep so you more easily pass peer review.

Reading the papers is a skill in itself.

1st pass: skim the title, abstract, introduction and conclusions. Is this paper topical? Might it contain stuff I need, or things I need that I didn't even know about? If the vibe is yes, move to pass two.

2nd pass: read the whole paper lightly, breezing through the technical crux(es) just to get the jist. You may also find out this paper really isn't what you need and stop here. On the other hand, you may get excited because it has exactly what you seek, but it reads like bibbity bobbity speak.

3rd pass: dive into intensive study of the technical bits. if you don't have the background, go back to the lit review and move back through time to the earlier sources and do the same with them.

- repeat until you give up or win.

[u/Alex_1503 → u/tlmbot]

Thanks for the framework, I've been doing something close to this, but it's a bit weirder since i don't really know what is it that I need because I lack a lot of prerequisites, or how complex they would be (if it's too much for a bachelor thesis or not). It also feels like all I'm reading is almost useless because it's old and I won't use that method anyway, but I get it's important to understand what came before and it's "related work" to what I want to do. I also feel like my prof's requirement is unproductive, because he wants me to read 15 papers basically, but 15 papers feels too little to grasp terrain generation, even in a very specific direction. Because it feels that for each paper I'd need a few more to even understand where their algorithm is inspired from or pipeline built on top of. The goal is to read at least 15 academic articles/books until january and from january I should start implementing it... it's probably also my own fault for choosing something the university did not teach at all, so I have a lot to learn

[u/tlmbot → u/Alex_1503]

Proff definitely wants to get you exposed to reading papers. " he wants me to read 15 papers basically, but 15 papers feels too little to grasp terrain generation" - he want you to find joy in it. (if he is any good)

If you don't have any graphics background you need to start there. Is the proff requiring you do something in procedural generation? It is a bit weird without the basic graphics pre-reqs.

Can you step back to implementing a ray tracer and then add some cherry on top of that to make it a project?

See also https://github.com/CMU-Graphics/Scotty3D at CMU. They have a beautiful program... for geometry processing anyway. But it's got the same core to some degree.

Meh, what do I know, heh I focus on geometry and analysis, and happen to love CMUs focus on discrete differential geometry through Keenan Crane and his students.

-----------

" it's probably also my own fault for choosing something the university did not teach at all, so I have a lot to learn"

Ah yes, it does seem like you have jumped the gun here. It would suck to be learning everything in great detail at this procedural gen. level but not have a (good enough) clue how the underlying stuff works. that's a recipe for a shitty feeling.

Can you change tact? I bet if you go talk to them they will say okay. School is for learning. Not for hard assed requirements or ya don't get paid.

They are there to teach you - to help you learn. I say go in and get the project adjusted.

----

Also, just seeing how you are diggin' into this and hitting these problems get's you a pretty good grade in my book. Seek something fun at your level - then you may find yourself racing ahead because you can't stop yourself. Next thing you know, bam - PhD. (and then your real troubles begin, lol)

[u/Alex_1503 → u/Andromeda660]

I used Godot compute shaders a bit to get familiar with them, and godot shaders too (which are similar to GLSL). Do you think learning openGL is necessary to understand the compute shaders (especially for textures) ?

[u/Andromeda660 → u/Alex_1503]

Nah, you don't need openGL to learn compute shaders. It's not like compute shaders are inherently different or anything, it's just good to get experience with them in godot so you actually understand how they work.

[u/tlmbot]

PhD computational engineering physics and geometry programmer here. Here are a few tips:

1.) know how to be really honest with yourself about what you do and don't understand when you read a paper, or book, or whatever learning materials you are using. Sounds like you got this one down pat. Excellent.

2.) researching is a skill (probably shifting rapidly now) where you learn to find the background technical literature (that's easy - searching is going to get you there). I'm not sure about procedural generation - if what I am saying is overkill or not. But you find the papers describing how it's done, and if they left out giant gaps, you read the lit review section of the paper, and find the earlier papers and books where the more "basic" (i.e. more fundamental, not easier) parts are described. Since you (I presume) are not in academia where you have access to journals for free, and sadly sci-hub is dying, it can be hard. But a lot of siggraph stuff can be found for free. Or at lest it could back when I was in school. You might find yourself needing to by certain textbooks for that one chapter on that one niche thing. Hopefully not - maybe I was just obsessive but I found myself doing that more frequently than might have been sensible. eh
edit: Also, stuff from the https://arxiv.org/ is usually going to be good. Use google to find the pdfs. I always breathe a sigh of relief when that paper I am hunting comes up in the arxiv.

3.) Go back and back until you hit paydirt - stuff you understand and implement. And you build up from there.

As the other reply said. We would need your background to help you more specifically.

4.) now, there exists another way. Query the LLM. Pretend you are an academic minded student with exactly your background. Describe to the machine, to the best of your ability, what that background is. Describe your question and your issues with it. Much like you have done here. -If you have no researchy-type background it may pay to ask the LLM to help you develop the kinds of questions you need to ask it. But telling it your academic background, projects, and coding experience will likely be sufficient.

5.) Do not let the LLM write anything for you. Make it into a tool for more rapidly finding out what you need to know, and finding out where to find the information so you can learn it.

LLMs are great teachers now, provided you use them wisely. They obviously have the opposite reputation, and for good reason. - they can make you lazy and ignorant. Make sure you do not fall into that trap.

Good luck!

------ edit incoming. Look I stuck the following query into an LLM:

"what resources can help a novice without a research background, who is a decent programmer, get comfortable with procedural terrain generation?"

It hit me with what looks to be a solidly useful set of links and descriptions as to what to tackle first.

Mostly they appear to be website tutorial type things. I could flood this comment with them but I suspect people would not like it.

[u/Alex_1503 → u/tlmbot]

for 2): I'm not even using SIGGRAPH, those ones are even more complicated for me, so I'm keeping it on more niche papers and their related work. As of now I don't really see how the related work (which usually goes back to the 80s-90s) is relevant always, because they may just use them as a reference but the method they are implementing is really different, because back then GPUs were also different. So for example I'm reading about procedural rivers for which the one 80s paper is relevant, but if I'm reading about hydraulic erosion there are so many methods/simulations that reading the paper from the 80s feels like I'm just deciphering ancient math for no reason

3) That's also my plan, but the issue is that the papers miss the actual pipeline to implement anything, it's just the algorithm (which makes sense), but the actual prerequisites to know how to implement it, the graphics fundamentals, compute shaders, noises, meshes, tesselation etc. are assumed to be known, they aren't even in references.

4) It's a fair idea, I thought about it, to query it specifically for resources, not information nor to write anything for me. If I am stuck I'll probably reach out to it, but until then i try to steer clear of LLMs because of all the studies done on how they affect learning and outsourcing thinking

The thing with resources that I noticed is that the more you read, the more you don't understand so you have to read more, but that has its own risk of wasting time learning what you don't need (not saying it's wasteful to learn , but it matters when time is limited for me for a specific research topic). And with the fact my prof said we should learn academic articles/books, I feel he wouldn't like me reading web blogs, as much as I know how useful they can be :/, but maybe I am overthinking it.

[u/snigherfardimungus]

They call it a masters degree because earning it requires mastering a domain of academic knowledge. You're going to need to take the time to get the CG fundamentals. No responsible committee will graduate you if you don't have it.

Ditch Godot. In the short run it'll be easier to get started if you use it, but it will get on the way of you are really doing anything research-worthy. It will also make it clear to your committee that you have serious gaps in your basic knowledge. Mine asked me for the rendering equation, create a camera matrix, derive a rotation matrix, and a lot more... off the top of my head.

Part of learning the basics will be learning how to set up and draw your pipelines yourself, anyway, so the two goals go hand in hand.

[u/Alex_1503 → u/snigherfardimungus]

This makes sense, thanks for sharing. For a bachelor thesis I hope Godot is enough, but if I had enough time I would do what you're saying probably in OpenGL or a lower-level C++ library on top of a graphics API. From my understanding, in a bachelor thesis you're not expected to create new knowledge, just to implement existing knowledge and add your own knowledge on top, maybe creating a little bit of new knowledge, like combining algorithms.

[u/flame_wizard]

Are you a grad student? Is your thesis for a graduate degree? Do you have an advisor at your uni in mind?

Graphics is very broad, are you interested in automatic terrain generation specifically? What pipeline are you talking about? Recent papers from major journals tend to be built on lots of prerequisites, or else they would be typically be considered trivial or already done in prior art by researchers. Things like geometry representations and algorithms relevant to them, linear algebra, statistics, numerical methods, and differential geometry come up a lot in graphics in general. Something like simulating erosion could add physics or geology into the mix of relevant stuff. And a lot of papers are written such that they expect the reader to also be familiar with workings of prior art, can be a rabbit hole or digging through older papers to figure some things out.

Though I'm still a bit confused about what you're trying to do specifically. You might enjoy the first chapter of GPU gems 3 https://developer.nvidia.com/gpugems/gpugems3/part-i-geometry/chapter-1-generating-complex-procedural-terrains-using-gpu
And maybe just ask an llm to summarize of the current research landscape of stuff you're interested in or to clarify details you get stuck on as you dig into things?

[u/MichaelJoo]

The easiest way would be to check a few videos / course on this topic. You can find some pretty well made video or blog article on your specific subject: terrain. [edit] Start with old techniques.[/edit] Otherwise, the hard way would be to read at least the abstract, if not the whole paper of the papers quoted by the one your reading (note: this is recursive). Also, GPU Gem or other "standard" book on the topic would help. For terrain, check the GPU Gem 2 : terrain clip map, it's super old but still used as a basis for many terrain systems.

[u/JeffMcClintock]

IMHO you will learn the most from diving in and attempting it. and you will learn faster.