While I understand the concept of LOD, I'm having a little trouble implementing it. Assume I have a number of models at different LODs and I want to store them in my Mesh class. What do I need to change (I already have a Mesh supporting one model). Do I have multiple VBOs (an array, with index dictating level perhaps?), buffer each model into it's VBO and bind the correct one when rendering? Or am I completely missing the idea?
What do I need to change
It really depends how you structure your vertices or indices. There are a thousand ways to achieve level of detail for models. You could as s3rius described, hold each LOD model in its own vertex buffer. Alternatively, depending on how you order your triangles or vertices, you can keep 1 vertex buffer and skip along the indices when you draw the triangles for varying quality.
For example, when you want full level of detail, you would render every vertex of the model. When you want half as much detail, you would render every other vertex.
Check out some of the links posted here.
LOD in modern games Always read up on modern practices.
Related
I am creating a pseudo-turn-based online strategy browser game where many people play in the same world over a long period(months). For this, I want to have a map of 64000x64000 tiles = 4 billion tiles. I need about 6-10 bytes of data per tile, making up a total of around 30GB of data for storing the map.
Each tile should have properties such as type(water, grass, desert, mountain), resource(wood, cows, gold) and playerBuilt(road, building)
The client will only ever need access to about 100x100 tiles at the same time.
I have handled the map on client side under control. The problem that I'm faced with is how to store, retrieve and modify information from this map on the server side.
Required functionality:
Create, store, and modify 64000x64000 tilemap.
Show 100x100 part of the map to the client.
Make modifications on the map such as roads, buildings, and depleted resources.
What I have considered so far:
Procedural generation: Procedurally generating whichever part of the map is needed on the fly. Making sure that given the same seed, it always generates the same map. The main problem I have with this is that there will be modifications to the map during the game. Note: Less than 1% of the tiles would be modified during the game and it could be possible to store modifications with coordinates in an outside array. Loading them on top of the procedural generation.
Databases: Generating the map at the start of the game and storing it in a database. A friend advised me against this for such a huge tile map and told me that I'd probably want to store it in memory instead.
Keeping it all in memory on the server side: Keeping it in memory in a data structure. Seems like a nice way to do it if the map was smaller but for 4 billion tiles that would be a lot to keep in memory.
I was planning on using java+mysql for back-end for this project. I'm still in early phases and open to change technology if needed.
My question is: Which of the three approaches above seem viable and/or are there other ways to do it which I have not considered?
Depends on:
how much RAM you got (or player/users got)
Is most of the tile map empty (sparse) ? Opposite is dense.
Is there a default terrain (like empty or water ?)
If sparse, use a hashmap instead of a 2D array.
If dense it will be much more challenging and you may need to use a database or some special data structures + cache.
You may detect hot zones and keep them in memory for a while, dead zones (no players there, no activity ...) can be stored in the database and read on demand.
You may also load data in several passes: first just the terrain, then other objects... each layer could be stored in a different way. For example the terrain could be perlin noise generated + another layer which can be modified.
I am working on a game scene with multiple objects that need multiple materials. I extensively searched online, but I could not find any satisfactory solution.
My scene will have like a river flowing by and the material there will require a separate shader anyway (it will combine many specular and normal maps into what would look like a river) then there is a terrain that would mix two (grass and sand textures) requiring another shader. There is also a player with hands and amour and all.
EDIT: Essentially I wish to find out the most efficient way of making the most flexible multiple material/shader implementation.
Briefly, there is a lot of complex objects around requiring varied shaders. They are not many in number, but there is a lot of complexity.
So using glUseProgram() a lot of times dosn't seem like the brightest idea. Also Much of the shader code could be made univeral like point light calculation. Making a generic shader and using if's and state uniforms could possibly work, still requiring different shaders for the river and likewise diverging materials.
I basically don't understand the organization and implementation of such a generic system. I have used engines like Unreal or possibly Blender which use Node based materials and allowing the customization of every single material without much lag. How would such a system translate into base GPU code?
If you really face timing problems because of too many glUseProgram() calls, you might want to have a look at shader subroutines and use less but bigger programs. Before that, sort your data to change states only when needed (sort per shader then per material for example). I guess this is always a good practice anyway.
Honestly, I do not think your timing problems come from the use of too many programs. You might for example want to use frustum culling (to avoid sending geometry to the GPU that will be culled) and early z-culling (to avoid complex lighting computations for fragments that will be overriden). You can also use level of detail for complex geometries that are far away, thus do not need as much details.
I'am working on a game with an low poly style. I have been searching for precedural terrain generation but there where only 3d or tile based tutorials.
INFO:
Langue is Java using the libGDX framework and released on android.
The terrain will be generated procedural while the game is running using a chunk loading system (for an infinite world).
The game terrain will be saved. And should be reloaded with the same terrain.
The Terrain can be convex (caves).
QUESTION:
Are there any good tutorials or libs?
If I use chunks to only load parts of the map some triangles vertices will contain 2 differen chunks how to manage these?
I have read that I shouldn't save / load a chunk to a file. But just generate the terrain using a seed. How do I tell the generator to not generate something that was removed previously?
What about entities save them to a file?
A few bits of general advice I have
Possible vertex overlap could be accounted for by defining and saving chunks with padding to account for the maximum a vertex could go outside of its chunk. Minecraft, for example, never had this problem because cubes line up very nicely. You could consider changing the geometry you're using. For example: define the world as cubes, and then apply an effect to move all vertices pseudo-randomly and thus hide that you're generating using cubes.
I would generate all terrain using a seed instead of saving and
loading from a file except for in chunks where something has been
removed. Those chunks will need to be saved. You could overwrite seed chunks with these.
Just like you said in your question, handle entities by: saving them to a .properties file or something. I would using a LinkedList<> or array[] with an abstract parent class to keep track of them in-game.
Some videos about procedural generation in general:
https://www.youtube.com/watch?v=JdYkcrW8FBg
https://www.youtube.com/watch?v=0ORcSjvESrA
This is all pretty abstract information, but I didn't want to leave this without any response. Hopefully someone with more experience in the particular area can give you more practical insight.
I've been writing a program to graph datapoints in Java. I need a lots of flexibility and speed so I don't want to use an existing library as much as possible. Right now, it essentially uses Graphics2D to draw lines and dots representing the points in a file of data.
My problem is, some of my datasets have upwards of 100,000 points.When it is going to be rendered with all full drag/zoom functionality, it is getting quite slow.
My question is, how can I reduce this dataset or make a simplification of it so that I can display the graph without changing the overall shape?
I could only draw every third point, for instance, but what if that skipped over and didn't display an important outlier? I could try averaging groups of points, but that could have the same problem.
And for services like Google Finance, where they probably have millions of points to display, how do they deal with this?
You may want to check for range differences between points before rendering them. Give them a threshold that they need to stay within in order to not be re-rendered.
I'm developing a small app for Android with OpenGL ES 1.x. There is no glBegin-glEnd-functionality so one has to define vertex (and color and texcoord) arrays for the objects to be drawn, and then use matrix operations to move, scale, and rotate them. This works nicely for large objects, nothing to complain here...
However, if one want's to draw small, "temporary" objects (e.g. just a line from point A to point B), things get a bit annoying. I have thus created some small utility functions such as:
DrawHelper.drawLine(starting point, ending point)
I have noticed two possible ways to do this. My question is which of these versions is preferred? Since we are dealing with such simple helper functions, and both methods are easy and understandable, one might as well write them as good as possible from the start, even if the potential speed gain would be very low. So please no "benchmark and identify bottlenecks first".. =)
Method 1:
The draw helper has FloatBuffer containing the points (0,0,0) and (1,0,0). I draw this line every time with the appropriate modelview matrix in place transforming the two points to the desired locations.
Method 2:
The draw helper has a dummy FloatBuffer and I use FloatBuffer.put to feed in the new points every time.
Method 1 is clearly (?) better for larger objects such as circles or other geometric shapes. How about a simple line or a simple triangle?
You always choose the method that involves fewer work. Applying a matrix multiplication is takes a lot more computations than two vector assignments. Also the matrix transformation approach sends ~2.5 times as much data to the GPU (a whole 4×4-matrix) than sending two 3-vectors.
OTOH Java adds the penality of going through a FloatBuffer.