#2.1 Creating a Game Engine in Java and OpenGL - Terrain Quadtree
Вставка
- Опубліковано 9 вер 2024
- This is the first part of the second episode of the OpenGL Game Engine Programming Series with LWJGL 3.
This video demonstrates the implementation of the Terrain Quadtree algorithm, which is the core of the Terrain Rendering System.
starting code of the video: github.com/ore...
finished code: github.com/ore...
The Game Engine of the programming series is derives from Oreon Engine: github.com/ore...
In ordner to upload the Tessellation episode I splitted up the Terrain Quadtree episode in two parts. Due to the horrible video quality of the code part I recorded this now in 1080p.
The second part is following in 2 days and the tessellation episode soon after.
HELP HERE AGAIN: After the first and this tutorial, the window is still black. Keep in mind that I know my GPU is dying. Can you give me a list of things to check?
the series is very amazing and informative
I think, everybody is amazed by you, and I am impressed, how wonderful your projects are. But you are writing code as if you were followed by two tigers. :D Keep up the good work, and I'd like to see more tutorials, if you can!
Would this approach also work with caves, so non 2d terrains (with the y of vertices pulled up and down). I mean, would this thing tesselate caves and overhangs and things like that?
7:23 Why do you need getters and setters for a static class variable? You'd reference it statically and not per instance anyway surely?
Error: modules.terrain.TerrainShader Shader creation failed
Just out of curiosity I would like to know why did you choose to use "0.333f" and "0.666f" in the "generatePatch" method? (12:15)
I use 16 vertices per patch, or in other words 4 parallel lines of 4 vertices. To tile a line with length 1 in equal parts you need to set the points/vertices at 0, 1/3, 2/3 and 1
Bist du deutsch?
Ja :D
@@oreonengine9444 Man erkennt es sehr gut am Dialekt ;) Wäre echt gut, wenn du die Serie weitermachst. Achte aber dann aber auch bitte darauf, dass du ein wenig mehr auf das eingehst, was du gerade schreibst. Es ist so nämlich sehr schwer nachzuvollziehen, was genau du gerade machst und wofür welche Klassen stehen :)
I have a question, do you know how to import an obj file from blender to an opengl jwjgl project?
You need an OBJ-parser. I wrote a custom loader but better is to use assimp. I will switch to assimp loading soon. It supports multiple object formats.
Thenx apprendist , his parser doesn't parse .mlt files
Nice one! Quick question, do you use separate draw call for each patch?
No, one draw call with a single shader pipeline
everytime i follow your code i end up with a black screen at the end, everytime, then i download it from you and it works, rinse repeat
There is any difference between this implementation and video #2 implementation?
No, I just wanted to split the video in two parts with better quality. When I upload the second part I will tag the #2 version as not listed
Ok ... thanks!!! Waiting for the next videos :)
Erstmal danke für dieses Video. So muss ich mir nicht das Quadtree-paper durchlesen :D. Kleine Klugscheisserei meinserseits: In der TerrainConfig verwendest Du 2 floats um den Scale der Map einzustellen (scaleY & scaleXZ). Beide verändern im Prinzip die gleiche Eigenschaft bei der Darstellung. Vielleicht wäre es hier besser, scaleXZ ganz zu streichen und als Wert 1.0 anzunehmen. Reduziert die Anzahl der Variablen. Zweite Sache wäre das Laden der TerrainConfig: Warum verwendest du nicht einfach die Properties-Klasse der Java Standard-Bibliothek um die Name/Werte-Paare aus einer Text-Datei zu laden?
Just wondering, what's the point of all those private fields if you always makes getter / setter ?
That's normal in java...
Because you can easily trace a call to a get or more importantly set function, but it can be tricky to trace a direct access of a field.
If you have time to put together a more comprehensive video for setting up your finished project in eclipse I think it would really help a lot of people. I followed this to the end and nothing is drawn, and don't even know where to start debugging. Thanks for the great videos though, hope you find some time to work on this series some more!
Thank you! you mean the finished code after every part? It's the same procedure as in part #0 download, import, convert to maven thats it
Maybe I do some research about OpenGL debug layers and make a video how to setup OpenGL debugging. But I don't know how extensive layers exist at all. OpenGL is difficult about error detection. Vulkan is much more friendly which it's validation layers, it tells you everything what possibly can go wrong
I followed part #0 but got errors, I'll try again. I'm following in C# and you can't add a float to a Vector2 like you do with location.add(gap/2f), is this the same as location.add(new Vec2(gap/2f)) ?
And yeh man this tutorial is great, terrain quadtrees, there's nothing else like it on the internet yet. Not sure what your future plans are but it'd be great to see how you set up instanced rendering for multimesh assimp imported models.
yes that is the same
I had to watch the video a second time because I wrote if(isleaf) isleaf=flase; instead of if(!isleaf) isleaf=true; and couldnt find it :/
Interesting system.
I see you are copying a lot of ways of Unity Which isnt a bad thing.
But sadly you use a lot of slow methodes of java. Hashmaps for iteration are bad. Linkedhashmaps are iterationfriendly.
If i would search more then i would maybe find a lot more tiny things that could cause issues.
Yeah I fix this, I didn't even say may code is perfect actually
Never said you said it. I am just pointing out issues. Thats my ocd.
yeah anyways, thanks for the hint with the hasmaps ;)
No problem. I suggest that you read into the Java src a lot more and check whats the best for you. Because ArrayLists and Hashmaps are not really good for everything. (Arraylists are only good if you know how much content you get and if the content stays and doesnt get deleted)
Alright, thanks, I bet are a lot of sections in my code that can be optimized. but I focus more on efficient GPU programming here, but I should go through the java code soon I guess