• 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.

Yno

Members
  • Content count

    4
  • Joined

  • Last visited

Community Reputation

200 Neutral

About Yno

  • Rank
    Newbie

Personal Information

  1. [quote name='Reflexus' timestamp='1348862986' post='4984845'] Hmm... wait, why do people rely on sampling so much? Be a little more procedural with the way you handle things. [/quote] In my case the terrain can be modified, it's not a static procedural defined shape. [quote name='Frenetic Pony' timestamp='1349045709' post='4985521'] Grass: Smartest I've seen is a grass map, greyscale map of grass density and then just spawn based on the map. A single easily generatable texture shouldn't be much memory. Of course you're only getting a single height layer, no grass in caves. But then why would you want that? I suppose if you did could always use a multi channel texture to store it and then have up to X heights depending on the channels you have available. [/quote] I don't see why I couldn't have grass in caves, the greyscale map just has to be three dimensional as you said. But once again, since the terrain can be modified I don't see why I'd want to store the grass density in any map, it should be part of the voxel data. [quote name='Reflexus' timestamp='1349058939' post='4985622']For your case, I recommend you just describe enough for the sampling to know what's appropriate i.e. a single scalar code for each voxel which corresponds to a 6-sided set of materials Examples: some material sets may entirely include the cliff texture, sometimes a mix of messy grass at the top and cliff on the sides, dirt ontop and red rock on the sides, or chalky-dirt with weeds on the top and cobble on the sides etc. [/quote] I did plan in fact some sort of merging to describe voxels with grass on top and rock on the sides, but I don't think that having materials that describe each side (or even two) is useful; if there is rock on the sides, so there is on top and everywhere else. I just thought of using a single bit to know whether there should be grass on top or not. For dirt on top and rock on side, just have a voxel layer of dirt on top of rock should be enough.
  2. You might be interested by [url="http://www.gamedev.net/topic/560675-triplanar-texturing/"]triplanar texturing[/url]. Using the local position and orientation of the vertices you can compute texture coordinates for arbitrary oriented/sized cubes. If you can use geometry shaders, you could also consider using them to generate the whole geometry of your cube.
  3. Thank you guys for your help and suggestions. [quote name='Reflexus' timestamp='1344395844' post='4967230'] You should experiment with more sophisticated normal map generation (which should also improve the automatic tri-planar texture blending). I'm thinking of using a "deeper sampling" into the voxel data to improve the distribution of things. Look at the bottom half quarter of your image. See the unrealistic, voxel-regular distribution of blending between grass and cliff? Also, near the cliff-slopes and thin spans of higher elevation, there shouldn't be any grass (either dirt or cliff). The diffuse lighting looks distributed good enough (although could be enhanced), but the texture distribution needs improvement more than anything else. [/quote] Sorry for the late answer, I was busy working on something else. I remember trying to sample a larger area for normal generation at first, but the only difference I could notice was a slight performance drop on geometry generation. I figured sampling 6 values was quite enough, especially if I'm doing some normal mapping or grass rendering (which I plan to do... later) on top of it. I agree that the texture transition looks quite bad though, I didn't really work on rendering yet. I quickly made a noise blending, and it looks a bit better though it still lacks some tweaking: [url="http://www.scengine.org/medias/view/144/without-texture-blending-noise#watch"][img]http://download.tuxfamily.org/scengine/screens/tb_sce-vterrain-texnoise1.jpg[/img][/url][url="http://www.scengine.org/medias/view/145/with-texture-blending-noise#watch"] [img]http://download.tuxfamily.org/scengine/screens/tb_sce-vterrain-texnoise2.jpg[/img][/url] [quote name='larspensjo' timestamp='1344944139' post='4969407'] [quote name='Yno' timestamp='1344392980' post='4967218'] The terrain geometry is generated as we move around [/quote] This will impose restrictions on the terrain generation. Any part of the terrain you generate can not depend on neighbor chunks. That makes it difficult to have "classic" terrain generation, for example making rivers by following the terrain from high to low elevation. This may be a necessary design limitation. [/quote] I was actually talking about geometry generation (via marching cubes) for rendering. The voxel generation is currently hardcoded in my test sample, the entire world is generated (or loaded from HDD) at the beginning. I don't know how I plan to generate the world if the player moves too close to the border. I'm aware of this kind of problem though, Shamus Young made a pretty nice [url="http://www.shamusyoung.com/twentysidedtale/?p=12076"]blog entry about it[/url]. [quote name='larspensjo' timestamp='1344944139' post='4969407'] Marching cubes have some limitations. When you have voxels of different types beside each other, it is tricky to determine out what texture to use. And then, some voxel should be drawn as cube (for example bricks).[/quote] With geometry shaders it seemed to be the easiest way to generate the isosurface (plus I had a nice article to steal from). I haven't tried using multiple materials yet, I guess you are right about texturing, but does it really depend on the isosurface generation algorithm? I don't plan to use the terrain to build any structure, so I should be OK with cubes. [quote name='larspensjo' timestamp='1344944139' post='4969407'] [quote]However I can't go around compressing/decompressing files on the fly as needed[/quote] Why not? Compressions is good not only for disk space, but also for communication bandwidth. But you may want to consider a very quick algorithm. The server should be able to cache chunks at several stages: on file, loaded to memory compressed, uncompressed in memory. You then need an algorithm that moves data back and forth between these stages. Use a checksum for each chunk, to make it easier and faster to communicate with the clients. And then, the clients also need to cache chunks. [/quote] Hm, it may not appear so but it is (except for the checksum) what I was trying to say, I probably didn't make myself clear. By "on the fly" I meant "from HDD to memory to HDD everytime needed, without cache", which is (I believe) too expensive. Anyway the caching system is pretty much done and working now.
  4. Hi, I've come to show you what I'm doing, to have your opinion or even feedback. Voxel terrains seem quite mainstream these days, so about 6 months ago I began creating my own, curious about what I could achieve. Like many people I was inspired my Minecraft and thus setup some goals I wanted to achieve:[list] [*]smooth surface (not huge pixel looking cubes); [*]dynamically editable (diggable); [*]"decent" view distance; [*]network streaming; [/list] Almost needless to say that I went for marching cubes, implementing the [url="http://http.developer.nvidia.com/GPUGems3/gpugems3_ch01.html"]GPU based technique[/url] described in GPU Gems 3 (the screenshots were good looking). I obviously made a LOD system. Each level being quite big (128^3 voxels for now), I split them up into smaller regions for generation speed purposes. The terrain geometry is generated as we move around, each slice of regions in the moving direction is computed when needed. Here come some screenshots: [url="http://www.scengine.org/medias/view/136/shadowed-terrain-using-the-deferred-renderer#watch"][img]http://download.tuxfamily.org/scengine/screens/tb_sce_vterrain_shadows2.png[/img][/url][url="http://www.scengine.org/medias/view/134/replacing-the-grass-texture-with-white-color-produces-snow#watch"] [img]http://download.tuxfamily.org/scengine/screens/tb_sce_vterrain_triplanar5.png[/img][/url] It's still work in progress but I'm quite happy with the results so far. No fancy rendering effects here. I'm currently working on the networking part. The server stores the voxels into an octree were nodes are chunks of like 32^3 voxels. Nodes are currently stored as in in the hard drive; though I didn't run any serious test for now storage will most likely become an issue. Fortunately this kind of data seems to compress quite well (each voxel is one byte long... for now). However I can't go around compressing/decompressing files on the fly as needed, especially if several clients are modifiying the terrain at the same time, which involves setting up some sort of cache system, which brings synchronization issues. Since I'm working on this I am considering many solutions, ideas are of course most welcome. There are a couple of things I'd like to do/try in the future, if you have ever done such stuff I'd be glad to know :)[list] [*](very?) long-range ambient occlusion, using each LOD well I believe giant cave could be nicely darkened; [*]conservative LOD: currently each level of detail erodes the terrain and small parts of it disappear. I was thinking of applying some sort of "max" filter when computing the LODs, and then shrink the surface alongside its normal to keep the terrain from getting fat. It would keep any piece of floating terrain, but fill holes very quickly; [*]I wonder what it'd be like to grow trees, making them match the surface of the terrain, which would add realism; [*]different materials (I've seen it being done in [url="http://forum.unity3d.com/threads/94224-Introducing-Voxelform-voxel-terrain-%28Marching-Cubes%29-with-real-time-deformation."]voxelform[/url]); [*]growing grass; I guess that would require quite a big amount of computing power, as it would need to keep in memory and regularly update areas where grass can grow; [*]CPU terrain geometry generation? [*]water... ? [/list] The project is open-source and part of my 3D engine, you can find more screenshots, some videos and of course the git repositories on my website: [url="http://www.scengine.org/"]http://www.scengine.org/[/url] You might however not be able to run the terrain demo since the example sources are not always up-to-date (especially when I'm working on them). Thanks!