• Create Account

# pyrotekgames

Member Since 27 Feb 2013
Offline Last Active Jun 15 2016 05:49 PM

### #5199457Voxel data- best way to get neighbors?

Posted by on 21 December 2014 - 06:42 PM

When working with voxels, I've noticed that chunks work better in cubical proportions. I cut up my 32x32x256 chunks into 8 32x32x32 chunks. This helped out some.

When meshing and performing AO calculations, I've seen three ways that work well:

1. Every chunk overlaps 1 voxel on each side, effectively becoming 34x34x34. This has been proven to be efficient by other engines (notably project's I've seen on this voxel reddit) but isn't the route I took.
2. Having a function like world.getVoxelAt(x, y, z). This isn't super efficient but basically solves the problem.
3. Setting up chunks in a network where I can call chunk->left->getVoxelAt(0, 0, 31);. This is the route I took, and it's worked great. Any block lookups or updates go from chunk to chunk, so this made the most sense to me. It has a feel like a signals and slots type of system and I personally have liked the way it all came together.

As for AO I don't grab the 26 surrounding blocks and go from there -- we're effectively dealing with faces when meshing so we only need the 8 blocks surrounding that face (don't need the top, since we're assuming the block is visible!). Each vertex needs some bit twiddling to figure out which three of the eight to use, but I've managed to have the system look like this:

```VoxelFace GreedyMesher::setAOX(VoxelFace face, Chunk* chunk) {
int aotx = (int) (face.pos.x + face.norm.x);
int aoty = (int) (face.pos.y + face.norm.y);
int aotz = (int) (face.pos.z + face.norm.z);

s[0] = chunk->getVoxelAtWP(aotx, -1 + aoty, -1 + aotz);
s[6] = chunk->getVoxelAtWP(aotx, 1 + aoty, -1 + aotz);
s[7] = chunk->getVoxelAtWP(aotx, aoty, -1 + aotz);
s[1] = chunk->getVoxelAtWP(aotx, -1 + aoty, aotz);
s[5] = chunk->getVoxelAtWP(aotx, 1 + aoty, aotz);
s[2] = chunk->getVoxelAtWP(aotx, -1 + aoty, 1 + aotz);
s[3] = chunk->getVoxelAtWP(aotx, aoty, 1 + aotz);
s[4] = chunk->getVoxelAtWP(aotx, 1 + aoty, 1 + aotz);

face.ao[0] = calcAOforVertex(s[1], s[7], s[0]);
face.ao[1] = calcAOforVertex(s[1], s[3], s[2]);
face.ao[2] = calcAOforVertex(s[5], s[3], s[4]);
face.ao[3] = calcAOforVertex(s[5], s[7], s[6]);

face.flipped = flip(face.ao);

return face;
}
```

The chunk->getVoxelAtWP()makes sure that the chunk uses the correct pointers to neighboring chunks when it needs to. This function is for the x-positive and x-negative faces; I have similar ones for the y- and z-axes.

I hope this helps. I'm not too great at covering every point so just ask if you have any questions about what I brought up

Best,

ST

Posted by on 10 March 2014 - 02:54 AM

Hello Mark, and welcome to GameDev!

1) I'm a college student myself, so I'd like to address a few things that you might be a little misled about. I'm currently in my junior year at university, and I've only now made a solid decision on what majors/minors/etc. I'm going to graduate with. You've got time to try some things out, so don't stress too much about making the perfect decision now! But having passions and a rough idea of what you might want is a great, great idea. College needs more students like that.

On top of that, don't be worried about free time in college. There's tons of it, lying everywhere around you. I take 2 students worth of classes (the usual is 3-4 classes, and I take at least 6), work over 20 hours a week to pay for college (outside of loans), I'm a part of a social club, and engineering club, and a game programming club. The social club takes no real time; the engineering club I'm making control systems and electronics for a UAV, and the game programming club I'm making a game. This game -- alone yes (at least while I make the engine), but many people to help me out along the way.

This sounds like a lot, but seriously -- I still have time to hang out, sleep, have a social life, and relax. I'm not saying do what I do but, whatever workload you have, you can make it work. Most places have gamedev clubs and such -- use those!! You can find the time to do the things you want -- like make games and a portfolio, if this is what you want to do -- if it's what you want and you have the passion for it (and a little bit of skill, and luck!).

When applying to internships, current projects are HUGE!!!!!! I've nailed so many internships talking about the project's I've done and showing off physical results and companies love that. If you have experience, that's worth a ton to a company -- you are more versed in how things go, and you've seen with your senses, exactly how things work and how things go wrong. I've been accepted to an internship because of a project I failed -- and failed as in a UAV turned into a flying flame-ball of death -- but the company saw the experience I gained, especially from the mishap, and how careful and how meticulous my planning is when working on future projects. All in all: experience is key.

2) I don't know much about this because I've only had internships and jobs as an engineer, but I've seen that people like seeing that you have knowledge of a lot, and can handle that, but really are phenomenal at one or two specific topics. It shows that you can learn quickly and retain knowledge, while you can also become an expert in things that need to be done by you, too.

3) I don't know

4)  I'd say the internship programs are best. I've had friends go through the program at Blizzard, and they loved it and learned a crazy amount of amazing things during their time there.

5) Got no experience here either, sorry!

I hope this helped. Sorry for the wall of text! I hope the college perspective can help you understand things and show you'll have plenty of free time

### #5134271An Ever Changing/Learing AI

Posted by on 24 February 2014 - 06:19 PM

This notion that in order to have learning AI you need programs that modify their own code is preposterous, but also very common. The divide between code and parameters is an arbitrary one, and it's much more productive to think of learning as changing parameters.

The other thing that should be mentioned is that adaptive AI is something you probably don't want in a video game. It's hard enough to debug a non-adaptive AI to make sure that the bad guys don't get stuck in corners or do other stupid things that break the illusion. If the AI can change once it's in the hands of the player, this can become a much harder problem, unless the adaptability is very limited and controlled.

Could you point me in the direction of a good starting place to learn the basics of AI. I don't intend to dive into it much as I stated I am mainly graphics oriented however I would like to have a better understanding of what I am talking about so that in the future I don't make myself look foolish like I did in this post.

I'd check out the first post on the AI Forum...it'll point you to many great books and sites to get your AI blood flowing!

### #5126424Getting started with procedural game engine programming

Posted by on 25 January 2014 - 10:30 PM

Hey! Good to see someone with similar interests as me I'm no expert in the field, but here's my experience:

1.) I generally like OpenGL because it's cross-platform. I work on a mac so DirectX is out for that....so I don't have much advice here.

2.) Depends on the language....I use Java and therefore follow the LWJGL tutorials. For C++, I'd probably go through the NEHE tutorials. There's also plenty of general openGL documentation all over the internet, as well as a few good programming channels on Youtube that do good tutorials (For example, I followed Oskar Veerhoek on youtube to get FBO's and such ironed out on my game engine using LWJGL).

3.) There's many good things online, for example this. That procworld website introduced me to using Grammars for creating procedural buildings and other structures. I also HIGHLY RECOMMEND Texturing and Modeling a Procedural Approach by David Eberly....it'll walk you through noise, fractals, perlin, texturing, terrain, etc. I constantly use it as a good source of procedural knowledge.

4.) Many things exist for game engine architecture, design, etc. Theres the David Eberly books (he seems to know his stuff, right...?) on game engines. They are good examples of a full game engine and documentation and discussion on why he made choices, but most of it is tailored to a general purpose engine. I've learned the most form looking at source code and documentation of engines that are already available to learn overall architecture tips.

As for language, C++ is fine and it's all up to you! I chose Java because I was more familiar with it and I could code so, so much faster in that language (5 years experience compared to my 1.5 years in C++). Since LWJGL is available for Java, that was great!

Good luck and have fun! If you're interested start a journal to document your work I'd love to see where this goes.

--ST

### #5124658Python or Java?

Posted by on 18 January 2014 - 09:07 AM

I second this: d4n1 has the right idea -- focus on learning game programming, not learning a language (if that's what you want to learn). Pick the language best for you (especially since you're starting out only a week ago) and learn the language. From there focus on game programming, not game programming in *this language I chose to learn*. The language is the tool; the real idea is using the best tool for the job.

### #5116634A book to match with “Mathematics for 3D Game Programming and Computer Graphics”

Posted by on 13 December 2013 - 12:53 AM

Just like the others have said above, you'll have a hard time finding a book for 3D graphics mathematics in Java. Also, as others have stated, LWJGL is a good place to start if you want to access OpenGL using Java -- this is what I'm using, and just because I'm more familiar with Java, I can get better performance with that language than with C++ (note I said with my experience; C++ will always be faster, its just that I know Java and how it works much, much better and can plan for that and I can program better using Java).

Also, there's the JMonkeyEngine Source Repository that you can always look at for examples (src is in the trunk folder). JMonkeyEngine is the source for an engine written in Java using OpenGL, and you can check out how they write their algorithms for mathematical computations (it's how I learned quaternions). It will take a little more work on your part (you need to navigate the source code) but you can learn sooooo so much from reading the source -- and it's in Java!! Check it out if you feel like it'll help

ST

### #5104151Need help finding an approperiate voxel engine.

Posted by on 24 October 2013 - 12:05 PM

Hello,

This sub-reddit has a lot of information on voxel gamedev, and happened to have a big list of engines too!

_ST

### #5098784Procedural Game Generation

Posted by on 04 October 2013 - 11:44 AM

Something that works great is noise. Use it for terrain, for building placement, for quest placement, for all types of different things. To make it fast, that will take some work and tweaking towards your particular case. For example, I use modified perlin noise to create terrain, biomes, and even creatures! There are tons of things easily reached from google or gamedev for how to use, make, and apply different types of noise.

-ST

### #5094563Getting Started with Graphics. Help?

Posted by on 16 September 2013 - 07:01 PM

I'd suggest looking at SDL (though I haven't used SFML or GLUT -- don't have advice for those...). I've used it quite a bit over the last year, and the nice thing about it is you can make hardware-accelerated games without even touching OpenGL!  It's great for starting with your first few games, and from there you can even stay within SDL and learn how to use OpenGL with SDL while still avoiding the System mumbo jumbo. It's definitely saved me lots of time getting things up and running for a prototype -- I've had 3D game prototypes (rough, but playable) up in less than an hour thanks to SDL because it makes window creation, management, and resource loading so easy to do.

Once you get the hang of things with SDL and OpenGL, then take a look at System programming, if that's what you're heading towards. Don't feel like you need to take that route, unless you know exactly why to take that route, too. Don't jump straight to the hard stuff; let someone else do some of the hard stuff so you can focus on the more important stuff -- the game, the graphics, etc.

Just my two cents....Good luck

--ST

### #5094251an algorithm or system to recognise hand-written text

Posted by on 15 September 2013 - 10:39 AM

The closest I've seen in my studies towards a goal like this is using neural networks with many, many, MANY test cases. In fact, the first example I had in my neural networks class was a program that could recognize the numbers a person wrote. Perhaps you just try looking for algorithms in that direction...? Honestly I don't know of any other algorithms that might do this...

I wish you luck!!

-ST

EDIT:  Here's the link to the class: https://www.coursera.org/course/neuralnets

Look at the first example (video 5 or 6) and they are showing how a neural network can figure out what number a person is writing. Note that this is just numbers....let alone letters, words, etc.

### #5089853Chunked LOD and Dual Contouring Help.

Posted by on 28 August 2013 - 11:08 AM

Hello!

So in my work right now, I've been working on destructible voxel terrain. I've gotten it down to a minecraft-like model, where there are chunks of fixed size and the viewing of the world is optimized (render near-to-far, etc). I have used 3D noise, created complex terrain, and have a firm grasp on procedurally creating terrain with noise. However, I want to take the next step now, and move on to using deal contouring and a chunked LOD system.

So my issues lie here: How would I go about this? Let me first say that I understand generally how these algorithms work. I know that dual contouring checks the edges of grid cells that change from in to out of the surface, and I know that chunked LOD takes into account how far away a chunk is from the viewer's chunk. I've also seen source code but...I think I'm just having trouble taking the step between general knowledge and full understanding down to implementation.

My main guiding questions are this: How do you know when to change level of detail? Does this LOD change in every (or most near chunks) chunk as you move? If so, how does this happen in real time?

My end goal is having destructible terrain with viewing distances much like real-life. I know this is possible, as I have seen at least a couple implementations, but I still can't bridge the gap. Any help??

Thanks,

ST

### #5074869Anyone here a self-taught graphics programmer?

Posted by on 02 July 2013 - 04:24 PM

A short story of my own:

I began in Python with my schooling, surprisingly my intro course was heavily graphics and gaming based (I'm a mechanical engineer anyway; computer graphics is my hobby). We used a nifty package to do the graphics, so creating 2D games was pretty simple. From there, I worked on software rendering for a while in Java and then C++, before reaching it's limits after about one year of software rendering of 3D geometry, and switched over to openGL. I enjoyed this decision I made; I learned a lot of the mathematics and theory behind most basic techniques in computer graphics, and I tend to do CPU techniques when I learn something new before porting it over to the GPU. ALso, the books I have built up have definitely led to a beautiful, compact library that I can constantly reference when working. Currently I'm working on a voxel terrain engine in C++ and openGL!

Not considering my first python course (which did not teach much of anything to do with computer graphics), I am completely self-taught. I feel like I get more out of it that way; I'm not forced to learn it; I learn what I want when I want!! I do hope to get to learn how to read others' code...and maybe a little bit of team experience when it comes to coding...but I don't regret any decision to keep this to a hobby.

--ST

### #5068737Question about how to store voxel data?

Posted by on 10 June 2013 - 01:38 PM

So a couple questions here. I'm currently working on a terrain/world-maker, using noise and fractals and such. I happened upon this great blog, chock full of a ton of information. A certain starting page of interest can be found here.

My first question is this: How would someone, using this guy's techniques of an Adaptive Octree, Dual Contouring, and QEF, store/retrieve voxels for this? My main point of confusion is the adaptive octree. Because he is using something like clipmaps, but in 3D (therefore called Adaptive Octree), I don't understand how this can be applied to some form of storage for the voxels. Is he storing voxels, then computing the new terrain? Or is he just computing the mesh in a chain form (point evaluation --> voxels --> DC and QEF --> mesh)?

Secondly, I'm wondering how he gets his surface normals from the voxels' edges. I know you can evaluate points in the terrain to get the normals at a certain point or edge, but what if you make changes to the terrain? Does this change the voxels, or does it just change the resulting mesh from the Dual Contouring with QEF? Sorry if this is a stupid question

By the way, I'm not looking for specific code, but more for an overall idea of how this can work. I've gotten noise and fractals to work well for me, and I have an implementation of dual contouring with QEF (mainly due to the same reasons the guy I'm talking about chose that transformation of voxels to meshes), and would like to understand how he stores voxels and uses the adaptive octree.

Thanks,

sT

### #5067504Procedural Terrain/World

Posted by on 04 June 2013 - 07:13 PM

Hello!

I've currently been working on an idea for an application that creates procedural terrain with weathered effects (basically, you can speed up simulation and weather on the terrain to shape it with some "history", if you want to). Unfortunately, I've hit a snag in my research -- how to look up material I can learn from!

I've started reading Texturing and Modeling, a Procedural Approach by David Ebert, but I have yet to grasp everything I can get from this book. I'm working with voxels that I can translate into triangle meshes. I've learned about using noise and other things to create height maps for terrain, but I'm looking for something else -- how to generate specific terrain.

What I mean here is that Deserts will have thin lines of different sediment on their mountains, where past rivers have dug down into the ground. Rocks look different in different biomes. Are there techniques to modeling things in a certain way, or techniques for realistic terrain, anyway? Does anyone have any resources or possible keywords to search with? my research is running a little dry :/

Thanks

BTW: This guy, on youtube: (link here) is sorta what I'm looking for. I've also seen his blog, but I'm still running low on research and leads . . .

### #5054786Discussion of Pokemon X Y visuals

Posted by on 18 April 2013 - 09:45 PM

Thanks.I had no prior knowledge how to search for that type of technique, now i know what it's called. While I start looking around, does anyone know of any good sources of the theory behind how to do this?

PARTNERS