What I did today

Miscellaneous Topics
#3321

I’m still working on world generation. I’m trying to create my own noise algorithm, instead of using Simplex or Perlin noise. I’m not referring to any tutorials or anything. I want this to be a challenge ;D

I can safely say that it’s going well. It’s starting to look more and more natural :slight_smile:

EDIT: The generation algorithm is fine, but the rendering process is too CPU-intensive. I can barely render an 18x18 world!

EDIT: I DID IT! I ACTUALLY DID IT! At first it wasn’t looking very natural, though I could make out the hills and all, but now it looks just as smooth as Simplex/Perlin noise! Of course, it’s way more CPU-intensive, but hey, it’s my own algorithm…and I did it!

#3322

Now you need to post a pic of the result here :slight_smile:

#3323

Here you go…actually, wait. A couple of things I need to explain. Firstly, I can’t render huge worlds (to be precise, 18x18 is the max world size) so don’t blame me. Still, you can make out the formations. Also, I set the minimum height to 15 blocks, so you can only see small hills and not awesome mountains. However, if I manage to optimise the generation and rendering process, I might be able to show you guys mountains!

I’m really proud of myself because I’m an OpenGL newbie and I never expected that the low-level API would be so easy to use. I hope you guys like the screenshots :smiley:

By the way, the first image only shows the surface being rendered. And yes, this is my own algorithm ;D Yippee!

#3324

If you are using VBO’s you should definetly be able to do more then 18x18x15.

I recently made this

http://puu.sh/lBp4x/c687796aa8.png

With a world size of 15153 chunks, where each chunk was 161616, but there is only 1311561 solid blocks, the rest are air, gives about 55 fps.

It is pretty poorly optimised, I could increase the performance by a lot if I spent the time on it. it currently completely renders every block.

to struggle to render 18x18x15, you must be doing something extremely wrong in your rendering, or your computer is very under powered.

If you are using VBO’s, try and minimise the amount of VBO’s you are drawing per call, this is the only optimisation that I implemented in mine.

Another would be to only render blocks that are exposed to an air block. (I did not do)

The next would be to only render the faces that are exposed to an air block. (I did not do)

#3325

Well, I only render blocks which are exposed to air, as you mentioned. And I am using VBOs, though I’m not sure how you’re rendering that many blocks. I don’t understand. My computer isn’t very underpowered, either. From what I learnt, VBOs are just objects you store in VAOs and VAOs are what represent the models. So doesn’t that mean I’m actually rendering VAOs and not VBOs?

What I’m doing every frame is…well, every block is the same VAOs, just with different textures and transformations (translation, rotation, scale (though they are all of the same scale)). So every frame I enable the attribute lists of the VAO. Next, I loop through every block, load their respective transformation matrices and render them (using glDrawElements(), not glDrawArrays()). I render the blocks individually, which means every frame I’m calling the render() method about 1000 times, then I unbind the VAO and disable its attribute lists.

The only optimization that can be made would be to reduce the number of draw calls every frame. If that’s what you meant, then how do I accomplish this? Instanced rendering, perhaps?

#3326

My first iteration of the engine worked kinda like yours, because I was reusing my Model class, which was mainly for the use of loading .obj files and rendering them, and only 1 model would fit into one VBO (or 1 model fitted into multiple VBO’s when it required multiple texture files).

I created one Model which was my cube, and rendered it for each block, changing its texture and its model matrix.

My second iteration then kept the same rendering code, but removed blocks that were not visible. This increased its FPS, but made the FPS very unstable, where the FPS was halfing for a few seconds, before returning back to normal FPS for a while.

My third iteration with SHC’s help, as I didn’t even notice I was doing it, I was getting the FloatBuffer of the matrix each frame, which was the cause of the very unstable fps, after the fix, it kept it stable.

My fourth iteration, was I seperated the code into chunks to reduce draw calls. every 16x16x16 blocks was put into a chunk, where I then put all those blocks inside one VBO.

So now instead of 409600 draw calls to render 160x16x160 blocks, it was now done in 100 draw calls, which gave a huge improvement. from about 6fps (first iteration) to 30fps (3rd iteration) to 142fps (fourth iteration).

EDIT:
Removed some lies, because I forgot the world size dimensions I used.

#3327

Forgive me, but I do not understand. I mean, VBOs are just objects to store data. I thought VAOs are the ones being drawn and VBOs are just data objects to be stored in VAOs. What do you mean when you say you’re drawing VBOs? Aren’t you actually drawing VAOs?

#3328

well, yes, I just always call them a VBO out of habit.

using the same way as you are to render, glDrawElements(…).

So 1 VAO per chunk, which is still 1 VBO per chunk.

#3329

But wait, how can you make it all one VAO if the blocks have different textures? In each chunk there can be stone or grass blocks, so how can you make it one VAO?

#3330

I am using a spritesheet.

You want as little binding as you can, and if you are using small enough texture files, you dont need 1 texture per file.

As I have 3 textures (stone, dirt and grass), all at 16x16 size. I can just pack them into a texture (I chose 256x256, so I can fit more textures if I desire).

You then can work out the new UV coordinates by a few lines of code to produce the UV coordinates for a certain 16x16 area in a 256x256 texture.

This now means I only need 1 texture bind, and I can have a lot of different blocks into one VAO.

#3331

Would instanced rendering give the same results, instead of packing the different cubes into a single VAO?

#3332

not sure never tried, but what I did was pretty simple implementation.

#3333

Thanks, mate. All I was doing was splitting a huge list of blocks into smaller 18x18x15 lists. My chunk rendering system is half finished.

#3334

nope :frowning:

As i know:
Best performance you can get from packing all Blocks from chunk to one VBO
(and use it with one texture atlas (sprite sheet))
Faster alternative: only shader render: raycast or calculate VBO with textures on GPU side.

And we don’t talking about LOD :wink:

#3335

Finished the SAT. Feel pretty good about it, but man am I mentally drained.

#3336

Just in case, I moved my backups of JGO to a sub-domain. You can now access it here:

http://jgorecovery.goharsha.com/

#3337

I’ve been messing around with fractals on shadertoy. Accidentally made a frozen over lake or something.

Please check it out, it looks much better with movement :smiley:

https://www.shadertoy.com/view/MdtGWH

http://puu.sh/lMxIr/9cddb3b8b8.jpg

EDIT: Slyth2727, did you just randomly medal my 10 month old post? lol

#3338

So, the good news is that I’ve managed to get dynamic atmosphere reflections working. I do this by rendering the procedural atmosphere to a low-res cube map and calculating a reflection vector for the water based on its normal. Here’s an exaggerated night-sky to show the effect.

The bad news is that I sent a mail to the person who made this shader asking a bit about how to optimize it, and was promptly told that the shader was under a non-commercial license, which means that I will not be able to use the exact source code from the ShaderToy example. Obviously was an overlook on my end, but it’s still a bit frustrating. In addition, the ShaderToy example doesn’t look as well when zoomed out as I had hoped. Since the noise octaves are based on sin(uv + noise) the waves have a clearly visible grid pattern to it, which doesn’t look good at all. The whole shader also proved extremely hard to optimize. The biggest performance issue came from how the normal was calculated by local differentiating (calculating 3 heights to get a gradient), which required a lot of heavy math. It was also difficult to precompute the expensive noise function as the hardware bilinear filtering only provides around 256 different steps between the filtered colors, causing the waves to stutter which in turn messed up the motion vectors (no motion for 3 frames, then pop -> entire thing is motion blurred for 1 frame). The noise function and the math itself was using an obscene number of sin() and cos() calculations, both for calculating noise and for the wave shape, and they’re not particularly cheap on GPUs.

Since I had to rewrite the entire thing anyway, I decided to change the function to something that I could calculate the gradient of analytically or even precompute. I ended up going with an RGB texture with the height in R and the XY gradient in GB, allowing me to just sum up the gradients (modified for amplitude and frequency of the octave) to get the height and normal with just a few texture samples. I’ve experimented with getting sharper wave edges by modifying the noise texture and it kinda works, but I still haven’t managed to reach the same quality as the original. At least it’s fast as hell now.

The next step is recalibrating the colors again for HDR. Gonna try to get a similar colors to the original.

#3339

A good pseudo-random number generator is this:


Requires GLSL 330, though.
I am using it for generating random rays in my raytracer, where the tiniest patterns would be very very noticeable.
But unlike the very popular function with the “fract(sin(dot(…)))” - which apparently everyone is using - it does not exhibit any patterns at any scale of the input values.

#3340

I got Vangardians selling excess items in their inventory successfully with very lightweight logic. The only bug is they sell too many of their things but I can see an easy fix. I felt happy to see they applied my business rules consistently and sold stuff I hadn’t thought they would need to.

For example, a Healer makes their cures and tonics by combining ForageBehavior, DoRecipeBehavior, GotoBehavior and SellStuffBehavior. ForageBehavior is configured with the items to forage for (weeds, beatles, toadstools…), and DoRecipeBehavior is configured with the appropriate herbalist recipes (strengthTonic, healingSalve…), while goToBehavior and SellStuffBehavior are truly generic and require no parametrization.

After fixing the little bugs, I will need to add the logic to buy needed items. Half the logic is there as characters keep track of a wishlist, so they just need to price up the most desired item and save accordingly. I will have to add in an escape hatch where characters can get into debt should they require an item that is essential for their career. For example, if a woodcutter has no money, and she breaks her axe, she would be unable to earn the money to buy a new axe…