• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.


  • Content count

  • Joined

  • Last visited

Community Reputation

129 Neutral

About Vangoule

  • Rank
  1. Using an actual sphere rather than using a cube seems a much harder way to actually accomplish what i'm doing. The cube system i'm using now shows no seams and the heights carry on perfectly due to the noise being 3D using the position of the vertex. The only thing i need to worry about at the moment is splitting it into patches which is the thing that's not working. GPU Tessellation would be nice but that doesn't change the fact i still need patches for it to work on. I'm at the point of ripping my hair out with this Quad Tree. The positioning just won't happen...
  2. The tesselator as far as i can tell is not good for LoD like this. I would still need to split it into patches for the tesselator to act on. I believe the tesselation acts on the full model and not just the area near you. Not to mention the fact that not many people have access to OpenGL 4.0
  3. I'll try get a video up soon. I've not been working on the project for a little while over frustration. This positioning stuff is really annoying. It should be simple but there's something screwing it up somewhere.
  4. I didn't give the whole project because the size is rather big but if it'll allow you to compile the whole thing too see it there's no problem. It was going to be OpenSource anyway. The problem is it relies on several libraries such as DevIL and SFML 2.0
  5. OpenGL

    Performance wise - Programming with the native libraries is probably the best bet. Glut has several issues such as not being able to control your main loop and how it exits. As well as some licensing issues that require the use of Freeglut. SDL/SFML/GLFW is probably the best bet if you want to make a cross platform window as these all give you control and some nice extra features. Personally i use SFML 2.0. Windows programming is very messy and un-intuitive, not to mention not cross platform (Obviously) and so i generally avoid it. I don't belive Glut has been updated in a long time either but i may be wrong. I'm quite sure that the window has little effect performance wise. It's more to do with how you develop your application. Just use whatever library you feel most comfortable with and allows you to get your applications running fast.
  6. Hmm, Here's my version of glew. However, the program was compiled on Windows 8 and a lot of the DLL's are from Windows 8 so it may be that which is crashing it.
  7. The value was found by trial and error but it's the point at which the two planes overlayer eachother. Though the value came to be that number because of the scaling and things. I changed the order in which i scale and translate everything and now the value is 168 which is the equivelant of the 'right' value from 0. Here's the source code now. I'll try and upload the actual application aswell. However, i'm not sure if it'll run on your machine. This should allow you too see what's happening. The planes have different height values so you can tell them apart. Moving the camera on to a plane should subdivide it once. It can be downloaded here: http://www.mediafire.com/?lk4zn5lmga3h99c
  8. The object class is just an object that can be added to the quadtree. In this case it's the camera. This just handles the subdividing depending on where it is. I could probably get rid of this when i switch to distance. As for the centers, I'm rendering using normal triangles and the rendering starts at the top left. So my 'centers' really ended up as corners. The problem is i don't know what numbers to be using in the positions. Through trial and error i got the NW quad to work properly but none of the others seem to. 
  9. Ok, So basically i kinda got it working... Half way atleast. I make the quads i add my camera as an object and the first subdivide is fine. However, the next thing that i subdivide leaves a big hole. It's probably due to positioning but i can't seem to find it. The source responsible for the terrain has been attached  
  10. Ok, So basically i kinda got it working... Half way atleast. I make the quads i add my camera as an object and the first subdivide is fine. Howeevr, the next thing that i subdivide leaves a big hole. I'll try upload a pic in a sec.
  11. Oh and as for Gaps. My noise function takes in a vec3 to calculate the height of a vertex. If a vertex is in the same place it will go to the same height. Therefore i should get no gaps. 'Hopefully' T-Junctions however will still exist. When creating the new patches - How are you 'linearly interpolating' them to scale them back up? Edit: I assume i just average between two vertices. However, my vertices are in an std::vector<glm::vec3> so it's only 1 dimensional. So i'm trying to get my head round it atm. Though i'm still wondering how to position my patches. I'll upload some pictures when i'm finished. Currently not using indices so i have well over 20 buffers. (Bad FPS incoming) I'll sort that out when it works.
  12. There is so much information about quad tree's. Everyone seems to do it differently. I'm currently experimenting in a separate project to try and get atleast one quad. I'll see how it goes. I'm not sure if i have enough information yet. I'll try get it working if not i'm hoping your code will save me from my problems. Thanks a lot for all the help. 
  13. Ahh that simplifies it a lot. By building it in the application it should theoretically subdivide infinitely. I'll read more later. Edit: So after reading the code. I understand that making the cube in the application will be easier. However, the style of your quad tree looks different to most the stuff i've found online. Lets say i have these faces and have a quadtree/quadarray setup for them. When i split the face. It creates the 4 children. However, how do i actually split the face and not just the quadtree. I remove the current geometry and create 4 new patches the same W and H but at a different scale as it's children? How do i scale/move/generate these new vertices to be in the right place.
  14. Currently i've got my normalized cube on the CPU i then send this through a VBO to the shaders. Here i apply perlin noise functions to create my height. I then choose what texture to use based on height with a change value made with sin cos and tan to make sure it's not a straight line of height.   If i can just implement a Quad Tree i'll be able to continue to create my procedural planet. This is my main goal right now.   So currently my cube has thousands of vertices when i export it from blender and load it into my application. I'd like to cut this loading time a lot. If i just load a unit cube without any extra vertices and sub divide it using the Quad Tree the shader will work out the heights for each vertex. So any source code or description more than 'Put your data in a QuadTree as a patch' will be helpful. I've been looking at this subject for a week now and still haven't got any further. I guess each node will have a struct which holds a certain amount of triangles. When it overflows - 'The camera gets closer' the node will subdivide and it's 4 children will each generate it's own data which will equal the size of the parent node but be in more detail. This is how i imagine the quad tree working. As for rendering instead of using a VBO per leaf would it not be easier to have 1 VBO per planet. I believe there are ways to do this using sub data or something like this.   So top priority: Implement Quad Tree. I can show source code of my project if necessary.
  15. Thanks for the reply. The bit on the sorting out which vertices belong to which face helps a lot. My main problem though is actually storing data in a Quad Tree. Most information from articles simply say - Store it in a quadtree in patches size n*n. How would i adapt a Quad Tree that is created like this - https://github.com/veeableful/Adaptive_Quadtree_Minimal to be able to hold data? Some source code would be much appreciated.