SpiderPig

Heightmaps are applied and look really good. There needs to be more work done on blending the heights together, but for an Alpha this is fine.

Finally got normal mapping working correctly. I'm using debugging heightmaps to identify each world and the square in the top left of each map tells me what the coordinate system should be for that world. I love it how the edges of each map blend nicely together with no extra work other than just normals. Next steps; Fix tangent & bitangent maps Re-apply heightmaps and generate rocky heights for the borders between worlds Apply gravity maps & get physics working again Generate biomes according to heightmap stamps used After all that I can finally start working on gameplay again.

Once again simply posting has helped solve the problem... This is not the correct order to multiply matrices in. localVertPos *= inverse(projectionMatrix); localVertPos *= inverse(entityMatrix); This is. localVertPos = inverse(projectionMatrix) * localVertPos; localVertPos = inverse(entityMatrix) * localVertPos; And the other issue of points all appearing in the centre of the mesh. Both vertex and geometry shaders need to be in the mask section of a shader family.

I have officially been driven mad by this issue over the last few days. Something I've had working in the past and thought I understood now doesn't want to behave. Here's a simplified example. I'll be creating vertices in the geometry shader and those new positions will need multiplying by the model and projection matrices. But I'm getting mixed result of vertices flying off screen and sometimes only one vertex in the centre of the model. I know I'm doing something wrong. Here I'm applying the shader to a grid made with CreatePlane and 8 x & y segments. It should be a flat grid of points but the code below makes them fly around with the camera, this is just one shot were they were in view. Even when I pass the entity matrix, projection matrix and raw vertex position as an output to the geometry shader I can't get it to work. I'm sure a quick discussion with guys will help resolve this. Geometry Shader Code. #version 450 #extension GL_GOOGLE_include_directive : enable #extension GL_ARB_separate_shader_objects : enable #extension GL_EXT_multiview : enable layout ( triangles ) in; layout ( points , max_vertices = 1 ) out; layout(location = 9 ) in flat uint inFlags[]; layout(location = 25 ) in flat uint inEntityindex[]; layout(location = 2 ) in vec4 inTexCoords[]; layout(location = 3 ) in vec3 inTangent[]; layout(location = 4 ) in vec3 inBitangent[]; layout(location = 5 ) in flat uint inMaterialIndex[]; layout(location = 0 ) in vec4 inColor[]; layout(location = 6 ) in vec4 inVertexCameraPosition[]; layout(location = 23 ) in vec3 inScreenvelocity[]; layout(location = 1 ) in vec3 inNormal[]; layout(location = 7 ) in vec4 inVertexWorldPosition[]; layout(location = 17 ) in vec4 inVertexPosition[]; layout(location = 9 ) out flat uint outFlags; layout(location = 25 ) out flat uint outEntityindex; layout(location = 2 ) out vec4 outTexCoords; layout(location = 3 ) out vec3 outTangent; layout(location = 4 ) out vec3 outBitangent; layout(location = 5 ) out flat uint outMaterialIndex; layout(location = 0 ) out vec4 outColor; layout(location = 6 ) out vec4 outVertexCameraPosition; layout(location = 23 ) out vec3 outScreenvelocity; layout(location = 1 ) out vec3 outNormal; layout(location = 7 ) out vec4 outVertexWorldPosition; layout(location = 17 ) out vec4 outVertexPosition; #include "../../../../../../../../UltraEngine/Templates/Common/Source/Shaders/Base/EntityInfo.glsl" #include "../../../../../../../../UltraEngine/Templates/Common/Source/Shaders/Base/CameraInfo.glsl" void main() { //This works, only the first vertex of every triangle should make a point and it does just that /*for (int vertex_id = 0; vertex_id < 1; vertex_id++) { gl_Position = gl_in[vertex_id].gl_Position; gl_PointSize = 4.0f; outFlags = inFlags[vertex_id]; outEntityindex = inEntityindex[vertex_id]; outTexCoords = inTexCoords[vertex_id]; outTangent = inTangent[vertex_id]; outBitangent = inBitangent[vertex_id]; outMaterialIndex = inMaterialIndex[vertex_id]; outColor = inColor[vertex_id]; outVertexCameraPosition = inVertexCameraPosition[vertex_id]; outScreenvelocity = inScreenvelocity[vertex_id]; outNormal = inNormal[vertex_id]; outVertexWorldPosition = inVertexWorldPosition[vertex_id]; outVertexPosition = inVertexPosition[vertex_id]; EmitVertex(); } EndPrimitive();*/ //Here I'm trying to prove that I can take a local vertex position and re-multiply it by the correct matrices //As f ar as I know to get the local vertex postion back I need to undo a few things first... //I actually don't know what the vertex 'w' component should be. I'm pretty sure it should be 1.0f... mat4 entityMatrix = ExtractEntityMatrix(inEntityindex[0]); mat4 projectionMatrix = ExtractCameraProjectionMatrix(CameraID, gl_ViewIndex); vec4 localVertPos = gl_in[0].gl_Position; localVertPos.z *= 2.0f; localVertPos.z -= localVertPos.w; localVertPos *= inverse(projectionMatrix); localVertPos *= inverse(entityMatrix); //This is what the vertex shader does as far as I can tell gl_Position = projectionMatrix * (entityMatrix * localVertPos); gl_Position.z = (gl_Position.z + gl_Position.w) * 0.5f; gl_PointSize = 4.0f; EmitVertex(); EndPrimitive(); } DisplayNormals.zip

Thanks for your input guys. I actually have the app id already - but I don't know how to make the page live with no download attached... is that as simple as publishing the page but not making a repo? (or what ever it's called, I forget) or do I make it coming soon page?

Oh right. Just wanted to check. What do you think about the swept culling issue?

In this shot the camera is very close to the terrain surface but you can see the patch hasn't updated to the highest LOD level. The terrain here has a y scale of 500. Do you need an example for this one?

Does anyone have any thoughts on releasing an alpha version of my game on steam as a free download? I thought about uploading it to something like itch.io but I want to use and test some steam features too. I'm thinking I could develop the game while it's on steam, get some feedback etc. and then later turn that free download into the demo for the final game. I'm just wondering though if this is a good idea or if steam should be avoided until ready for early access phase. Mainly for things like reviews. But I'm curious to hear your thoughts.

So the max instance count is about 65k but does that include things like sub-passes and meshes? I mean can we have 65,000 instanced cubes or with 2 sub-passes are we limited to only 32,000 cubes? Also, with your Instanced geometry benchmark code, I've added in swept culling and a few more cubes. Even with swept culling enabled it doesn't make much difference. In my game I only have a few thousand instances and it doesn't hep much there either. Can I turn off culling for particular objects or all of them? I'd like to test the performance of both options. #include "UltraEngine.h" #include "ComponentSystem.h" using namespace UltraEngine; int main(int argc, const char* argv[]) { const int count = 32; RegisterComponents(); //Get the displays auto displays = GetDisplays(); //Create a window auto window = CreateWindow("Instanced Geometry", 0, 0, 1280, 720, displays[0], WINDOW_CENTER | WINDOW_TITLEBAR); //Create framebuffer auto framebuffer = CreateFramebuffer(window); //Create world auto world = CreateWorld(); //Create camera auto camera = CreateCamera(world); camera->SetPosition(0, 0, -count * 2); camera->SetClearColor(0.125); camera->SetDepthPrepass(false); camera->AddComponent<CameraControls>(); camera->SetSweptCulling(true); camera->SetOcclusionCullingMode(false); //Create box auto box = CreateBox(world); box->SetCollider(NULL); auto mtl = CreateMaterial(); mtl->SetColor(0.5f); mtl->SetShaderFamily(LoadShaderFamily("Shaders/Unlit.fam")); box->SetMaterial(mtl); //Create instances std::vector<shared_ptr<Entity> > boxes; boxes.reserve(count * count * count); int x, y, z; for (x = 0; x < 32; ++x) { for (y = 0; y < 32; ++y) { for (z = 0; z < 64; ++z) { auto inst = box->Instantiate(world); inst->SetPosition(3.0f + float(x - 1 - (count / 2)) * 2, 3.0f + float(y - 1 - (count / 2)) * 2, 3.0f + float(z - 1 - (count / 2)) * 2); boxes.push_back(inst); } } } box = NULL; //Fps display auto font = LoadFont("Fonts/arial.ttf"); auto sprite = CreateSprite(world, font, "", 14); world->RecordStats(true); sprite->SetRenderLayers(2); sprite->SetPosition(2, framebuffer->size.y - font->GetHeight(14) - 2, 0); auto orthocam = CreateCamera(world, PROJECTION_ORTHOGRAPHIC); orthocam->SetRenderLayers(2); orthocam->SetClearMode(ClearMode(0)); orthocam->SetPosition(float(framebuffer->size.x) * 0.5f, float(framebuffer->size.y) * 0.5f, 0); //Main loop while (window->Closed() == false and window->KeyDown(KEY_ESCAPE) == false) { //Check for failed renderer initialization while (PeekEvent()) { const auto e = WaitEvent(); if (e.id == EVENT_STARTRENDERER and e.data == 0) { Notify(L"Renderer failed to intialize.\n\n" + e.text, "Ultra Engine", true); return 0; } } sprite->SetText("FPS: " + String(world->renderstats.framerate)); world->Update(); world->Render(framebuffer, false); } return 0; }

I think I've fixed it! Thanks very much for your help, with your input it made me look in the right places. It was the sun direction calculation, I had missed a simple multiplication.

Okay, this position makes the sky black. sun_pos = Vec3(-0.324064016,0.825100005,-0.462809354); Yet changing the y to be 0.835 instead of 0.825 works. sun_pos = Vec3(-0.324064016,0.835100005,-0.462809354); Its a shader issue. I'm getting closer.

I just noticed your texture creation method; _dataTexture = CreateTexture(TEXTURE_2D, 64, 32, TEXTURE_RGBA32, {}, 1, TEXTURE_DEFAULT, TEXTUREFILTER_NEAREST); I leave my type as TEXTURE_RGBA and convert to floats like this - float BytesToFloat( in vec4 pixel ) { return intBitsToFloat( ( int( ( pixel.w * 255.0f ) ) << 24 ) | ( int( ( pixel.z * 255.0f ) ) << 16 ) | ( int( ( pixel.y * 255.0f ) ) << 8 ) | int( ( pixel.x * 255.0f ) ) ); } Would that function still work with the type TEXTURE_RGBA32 you think? I also use TexelFetch instead of sample.

Sweet! That should work better. As far as using the buffer, I had it working fine on some smaller applications which leads me to believe there's a bug with my shader. Pity we can't debug shaders....

Something that tells me it's not a problem with SetPixels is that if I poke the buffer with a constant value it doesn't flicker - ever. sun_pos = Vec3(1, 1, 0).Normalize(); auto index = 0; buffer->PokeFloat(index, sun_pos.x); buffer->PokeFloat(index + 4, sun_pos.y); buffer->PokeFloat(index + 8, sun_pos.z); texture->SetPixels(buffer);

I can't seem to reproduce this on a smaller scale. It's more than likely an issue with the shader itself but I can't for the life of me narrow it down. Anyway I've attached code and shaders if someone would like to take a look as well. It's like the shader doesn't like some of the vectors of the sun position and it causes it to flicker black sometimes. Any help is appreciated, I'll be tackling this in the shadows. #include "UltraEngine.h" #include "ComponentSystem.h" using namespace UltraEngine; int main(int argc, const char* argv[]) { auto displays = GetDisplays(); auto window = CreateWindow("Ultra Engine", 0, 0, 1280 * displays[0]->scale, 720 * displays[0]->scale, displays[0], WINDOW_CENTER | WINDOW_TITLEBAR); auto framebuffer = CreateFramebuffer(window); auto world = CreateWorld(); world->RecordStats(true); auto camera = CreateCamera(world); camera->SetClearColor(0.125); camera->SetFov(70); camera->Move(0, 2, 0); camera->AddComponent<CameraControls>(); auto light = CreateDirectionalLight(world); light->SetRotation(45, 35, 0); light->SetColor(2); auto plane = CreatePlane(world, 100, 100); auto sphere = CreateSphere(world, 512, 32); auto mat = LoadMaterial("Materials\\DynamicSky\\DynamicSky.mat"); sphere->SetMaterial(mat); auto size = 8; auto buffer = CreateBuffer(size * size * 4); auto texture = CreateTexture(TEXTURE_2D, size, size); mat->SetTexture(texture, 15); while (window->Closed() == false and window->KeyDown(KEY_ESCAPE) == false) { Vec3 speed = Vec3(0.02, 0, 0); light->Turn(speed.x, speed.y, speed.z); auto yoffset = 300; auto dir = Vec3(light->matrix.k.x, light->matrix.k.y, light->matrix.k.z).Normalize(); auto sun_raw_pos = Vec3(-dir.x, -dir.y, -dir.z); auto camera_range = camera->GetRange().y; auto sun_pos = Vec3(-dir.x, -dir.y + (yoffset / camera_range), -dir.z).Normalize(); auto index = 0; buffer->PokeFloat(index, sun_pos.x); buffer->PokeFloat(index + 4, sun_pos.y); buffer->PokeFloat(index + 8, sun_pos.z); texture->SetPixels(buffer); auto stats = world->renderstats; window->SetText("FPS : " + WString(stats.framerate) + " --- verts : " + WString(stats.vertices) + " --- polys : " + WString(stats.polygons) + " --- instances : " + WString(stats.instances)); world->Update(); world->Render(framebuffer, false); } return 0; }

I've been using a texture to store variables for a lot of my shaders. I've just decided today to see if I can update those variables in real-time. While it does work, I am seeing a bit of flicking - which in this case I'm assuming is due the to fact that when I'm setting a textures pixels there may be a few shader updates were that information is either gone or invalid? I've tried both render hooks as well. HOOKID_TRANSFER reduces it a bit but not completely. Just wondering if this is a good idea before I continue with it. buffer->PokeInt(index, value); texture->SetPixels(buffer);

A much better idea, thanks.

Nope. VS2019 doesn't crash either. Is this normal? I'm sure it never used to be.

No just the one. I'm doing an experiment in VS22... this program below doesn't crash. It does give some warnings. But in some situations it won't even do that. I think in my issue above I'm accessing an element in the array that goes beyond it's size. But it should crash at the array saying it's trying to access an an element that does not exist. I'm going to test this in VS19... it might be a bug with 2022. #include <iostream> int main() { int* myArray = new int[256]; for (int index = 0; index <= 256; index++) { myArray[index] = index; } int value = myArray[300];//will crash here if I make it 512 instead of 300 }

Project won't compile in VS2019 unless build tools v143 is installed but it seems it can't be installed on older version. It can only be used with VS2022. Changing the build tools to use 2019's v142 results in other errors. Probably because it needs something that v142 lacks.

VS2022 is terrible with intellisense not working as it should (mainly with larger projects) and crashes not showing the right info. Like this, I've got an access violation because it says spawn is empty, yet I'm checking if it's nullptr before I execute that code and it's always worked before. Unless there's a better way of checking a shared_ptr is empty?? This code has always worked until I change something else that seems irrelevant - obviously it's not, but... I've had many similar errors that when I finally track down the issue it has nothing do to with what VS is telling me. The only thing that might make this type of error possible is multi-threading but I'm not using threads. Hence I'd like to try using VS2019 and see if that gives me any better info. The only problems with shared_ptr's it seems is that some crashes do take you to weird headers and give wrong debugging info. I am curious if anyone else has had problems like this...

Should Ultra be able to be compiled in VS2019?

That is interesting. After about a minute the spheres vanish for 10 or so seconds too. Near to two minutes they vanish again and the shadows do to. Well on my end anyway. Visual Studio shows RAM all over the place, it stabilizes for a bit but then climbs again.