Jump to content
  • Advertisement
QQemka

OpenGL A batch of opengl questions

Recommended Posts

Hello. I am coding a small thingy in my spare time. All i want to achieve is to load a heightmap (as the lowest possible walking terrain), some static meshes (elements of the environment) and a dynamic character (meaning i can move, collide with heightmap/static meshes and hold a varying item in a hand :) ). Got a bunch of questions, or rather problems i can't find solution to myself. Nearly all are deal with graphics/gpu, not the coding part. My c++ is on high enough level.

Let's go:

Heightmap - i obviously want it to be textured, size is hardcoded to 256x256 squares. I can't have one huge texture stretched over entire terrain cause every pixel would be enormous. Thats why i decided to use 2 specified textures. First will be a tileset consisting of 16 square tiles (u v range from 0 to 0.25 for first tile and so on) and second a 256x256 buffer with 0-15 value representing index of the tile from tileset for every heigtmap square. Problem is, how do i blend the edges nicely and make some computationally cheap changes so its not obvious there are only 16 tiles? Is it possible to generate such terrain with some existing program?
Collisions - i want to use bounding sphere and aabb. But should i store them for a model or entity instance? Meaning i have 20 same trees spawned using the same tree model, but every entity got its own transformation (position, scale etc). Storing collision component per instance grats faster access + is precalculated and transformed (takes additional memory, but who cares?), so i stick with this, right? What should i do if object is dynamically rotated? The aabb is no longer aligned and calculating per vertex min/max everytime object rotates/scales is pretty expensive, right?
Drawing aabb - problem similar to above (storing aabb data per instance or model). This time in my opinion per model is enough since every instance also does not have own vertex buffer but uses the shared one (so 20 trees share reference to one tree model). So rendering aabb is about taking the model's aabb, transforming with instance matrix and voila. What about aabb vertex buffer (this is more of a cosmetic question, just curious, bumped onto it in time of writing this). Is it better to make it as 8 points and index buffer (12 lines), or only 2 vertices with min/max x/y/z and having the shaders dynamically generate 6 other vertices and draw the box? Or maybe there should be just ONE 1x1x1 cube box template moved/scaled per entity?
What if one model got a diffuse texture and a normal map, and other has only diffuse? Should i pass some bool flag to shader with that info, or just assume that my game supports only diffuse maps without fancy stuff?

There were several more but i forgot/solved them at time of writing :)

Thanks in advance

Share this post


Link to post
Share on other sites
Advertisement

I don't want to discourage you, but it sounds like you may not understand just how ambitious this project is. You have listed several features that would be a whole project on their own, especially if you're just learning graphics programming, and many of your questions relate to optimizations.  I've broken down some of the features you described, and I recommend picking just one to start. Remember that the project you actually finish by implementing a simple solution will teach you more than the one you abandon by trying to over-optimize too early. 

Heightmap - You need to load textures of different types and precisions, sample the height map and generate a terrain mesh, figure out how to distort your UV's and normals so textures and lighting look correct on it. From there you can start looking at using noise functions to make the terrain more unique, or using height values to blend between different textures to show climate types. 

Heightmap (Part 2) - Creating a lookup table for your terrain texture comes with headaches due to sampling artifacts, on top of the issues you've mentioned. Save this one for last. 

Collisions - Not really a graphics thing at all, so OpenGL won't be helpful for it. 3D entity/entity collision and entity/terrain collision are projects unto themselves. A physics library could be used instead of implementing it from scratch. Store the bounding volumes per instance to start with.

Dynamic character - Does the character have a mesh to import? Is it animated? If one or both of these things are true, it's a decent project on its own. If the character can carry and move objects around, that is yet another feature both here and in the "collisions" project. 

Other stuff:

- If you need to draw them, just make a vertex buffer for your AABBs and call it a day. This won't be the big bottleneck of your project for a long time.
- The easiest way to handle the presence/absence of some textures is with that boolean flag. Optimizing to avoid that is yet another project, and is often done by sorting your draw calls based on material information.  For now just stick with the boolean. 

Share this post


Link to post
Share on other sites

This would be significantly easier with an off-the-shelf engine (such as Unreal or Unity), which already have support from things like height-mapped terrain, animated meshes, physics, etc.

Share this post


Link to post
Share on other sites

Man, the guys above are too dire. I wrote most of this same stuff when I was fifteen, what’s with all this “this is hard to do without an engine” nonsense? Don’t know what the point is if we’re not going to help the newbies do real work. Let’s get down to it.

Terrain: it’s a nice idea that might need a few tweaks. My suggestion is to look up terrain “splatting” or “splat maps”. It’s not quite what you asked for but I think it’ll be helpful.

Collision: object space AABB per model, world space AABB per instance.

Drawing collision: I prefer to run these and all other debug rendering through a separate render pipeline based entirely on dynamic buffers and streaming vertex rendering. This makes it a lot easier to add additional displays/modes and info.

Shaders: both good choices, roll with what works ;)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!