Search the Community

Outputting vec4(gl_FragCoord.xy / DrawViewport.zw, 0.f, 1.f) as outColor[0] for all the scene geometry fragments into viewport directly: Outputting vec4(gl_FragCoord.xy / DrawViewport.zw, 0.f, 1.f) as outColor[0] for all the scene geometry fragments into texture buffer and then assigning this texture values to the surface.basecolor: I had to reorient gl_FragCoord to (gl_FragCoord.x, DrawViewport.w-gl_FragCoord.y) for one of the cameras in order to achieve the pixel-perfect dithering effect between two cameras.

vec3 adjustSaturation(vec3 color, float saturation) { // Convert color to grayscale float gray = dot(color, vec3(0.299, 0.587, 0.114)); // Blend the original color with the grayscale version return mix(vec3(gray), color, saturation); }

Would it be possible disable shadows for a single light in the fragment shader, with some shader manipulation?

Thought I'd show off my node editor for Ultra Engine Shaders. Currently I'm developing it as I develop my game, so features get added as I need them. But I'd love to hear your feedback and if you'd like me to add something I'm sure I can oblige. ShaderMaster_v1.3.zip Before use, you need to set the path to UltraEngine like this so it can find the tools and shaders. You will also need to copy 'FragmentCustom.glsl' to 'UltraEngine\Templates\Common\Source\Shaders\PBR' in order to use the fragment shader nodes. Then to create a new project go to File->New Project and enter in a name. PBR is the only available at the moment and you can choose PostEffect from the right drop down - but this has not been tested in some time! Feel free to explore it though. Add a file to the project by clicking the file icon with the '+'. Below are the files associated with one of my projects. Macros are also visible when the checkbox is checked. Macros are functions that can be used between projects. Create a function, right click the function file and choose 'Convert to Macro'. The function will be removed the current project and added to the macro folder. Choose a file type, this is either a shader stage or a function or definition. I've used the fragment shader extensively. I have used the vertex and geometry shaders though there may be bugs here. Please let me know. Tessellation and Compute stages aren't working yet. Select a file from the list on the right to open it and right click in the node area to get a menu of all the available nodes. I'll make in depth tutorials on this later if any one is interested as there's a lot more to cover. Right now it's there to play with. An example of the fragment shader for my voxel terrain.

I have packed integers and floats into a texture to use in my shader. Information is packed into the texture by poking a buffer and then assigning that buffer to an RGBA texture. The following code extracts an integer from a texelFetch result in the fragment shader. It seems to work well. int BytesToInteger( in vec4 pixel ) { return ( int( ( pixel.w * 255.0f ) ) << 24 ) | ( int( ( pixel.z * 255.0f ) ) << 16 ) | ( int( ( pixel.y * 255.0f ) ) << 8 ) | int( ( pixel.x * 255.0f ) ); } However the same process does not work for floats and I'm sure there is a reason why but I can't figure it out. Any one know the answer? float BytesToFloat( in vec4 pixel ) { return float( ( int( ( pixel.w * 255.0f ) ) << 24 ) | ( int( ( pixel.z * 255.0f ) ) << 16 ) | ( int( ( pixel.y * 255.0f ) ) << 8 ) | int( ( pixel.x * 255.0f ) ) ); }

In this post, I want to introduce you to my GitHub repository: https://github.com/klepto2/UltraEngineUtilities Currently, there is not that much available, but I am working on adding more utilities and helper classes, which will help to work with UltraEngine. I had the privilege to be one of the first users of UltraEngine and was able to see the enormous amount of potential right from the beginning. So with the repo, I want to give some of the small or bigger helpers I have developed or made compatible for UltraEngine to the public. Available Features: namepace UltraEngine::Utilities::Shader ShaderCompiler A class which allows you to compile UltraEngines glsl-shaders to SPIRV format from code. ShaderWatcher This class uses the UltraEngine::FileSystemWatcher to watch changes for all available shaders used by your program It parses the ShaderFamilies Keeps track of includes Recompilation of shaders as soon as the shader file changes Automatically reloads shaders when the compilation was succesfully Sample code: How To use the Shadercompiler: #include "UltraEngine.h" #include "ComponentSystem.h" #include "include\Utilities.h" using namespace UltraEngine; using namespace UltraEngine::Utilities::Shader; int main(int argc, const char* argv[]) { auto compiler = CreateShaderCompiler(); auto result = compiler->Compile("Shaders/GUI/WidgetBlock.frag", "Shaders/GUI/WidgetBlock.frag.spv"); if (result->IsSuccesfull()) { Print("Shader compiled succesfully!"); for (auto f : result->GetIncludedFiles()) { Print("Shader includes: " + f); } } else { Print("Shader compilation failed!"); Print(result->GetError()); } ... } How to use the ShaderWatcher: #include "UltraEngine.h" #include "ComponentSystem.h" #include "include\Utilities.h" using namespace UltraEngine; using namespace UltraEngine::Utilities::Shader; int main(int argc, const char* argv[]) { auto watcher = CreateShaderWatcher(); watcher->Start(); ... } Future Features: Multiple Widgets ContainerWidgets: FlowPanel StackPanel TableLayoutPanel Scintilla Integration plain Scintilla Wrapper Advanced SyntaxEditor -widget will encapsulate some advanced features like inlining etc. Vulkan-Utilities: A port and slightly modified Version of Sascha Willems https://github.com/SaschaWillems/Vulkan/blob/master/base/VulkanTools.cpp I am as well working on some more advanced stuff, but there i have to decide how to publish them. ComputeShader-Integration Real-time PBR-Environment-Calculations Atmospheric scattering Ocean and Water rendering Here are some Screens and Animations showing some of the above Features:

As well as trying out texture atlases I'm looking into textures arrays too, but am having trouble finding information on how to set it up. This is what I have so far; Material* mat = Material::Load("Materials\\terrain.mat"); Texture* texture = Texture::Load("Terrain\\beach_dirt_b.tex"); OpenGLShader* shader = (OpenGLShader*)mat->GetShader(); int _width = texture->GetWidth(), _height = texture->GetHeight(); char* buf = new char[texture->GetMipmapSize(0) * 4]; texture->GetPixels(buf); glUseProgram(shader->program); GLuint _buffer; glGenTextures(1, &_buffer); glActiveTexture(GL_TEXTURE0); glBindTexture(GL_TEXTURE_2D_ARRAY, _buffer); glTexStorage3D(GL_TEXTURE_2D_ARRAY, 1, GL_RGBA8, _width, _height, 1); glTexSubImage3D(GL_TEXTURE_2D_ARRAY, 0, 0, 0, 0, _width, _height, 1, GL_RGBA8, GL_BYTE, buf); Part of the Fragment Shader; #version 430 layout (binding = 0) uniform sampler2DArray tex; //in main() outcolor = texture(tex, vec3(coords.x, coords.y, 0)); All I get is total blackness on the terrain. Wondering if any of you guys know how to implement this? If needed I can make a small test program and upload that. A link I used; https://ferransole.wordpress.com/2014/06/09/array-textures/

I'm currently trying to write a shader that makes every triangle of the mesh point to the position of the camera regardless of the camera's rotation. I think I can multiply the vertex positions in the vertex shader by a one of the matrices but I'm not sure which one or how. And I think the camera matrix will rotate the triangle to the same orientation as the camera and not just point to it's position? Basically I need the vertex shader (or geometry if it's easier) to do what Entity::Point() does but on each triangle and not the mesh as a whole. Anyone got any ideas on how to do this? ? EDIT : I've been getting the direction the camera like this; normalize(vsModelVertexPosition.xyz - cameraposition)

I'm looking for someone to write a terrain shader that will texture a terrain model based on height and slope. I want it to use uniforms for the height and slope of each layer so I can change them through code. It will need to use at least four layers - each with diffuse, normal and specular maps. If it can use more layers that would be better. Also I would like the option to use an alpha map to further control where textures are shown. The terrain is a cube, pictured below; Would like it by the end of the month if possible. Will pay for the work too. PM me if interested.

I've put together a quick shader that will show the object in wire-frame and draw lines to show the direction of each vertex normal. But the normal's don't seem to be acting correctly. Is somehow able to show me what I'm doing wrong? I have a feeling it something to do with the cameraprojection matrix, but unsure how to fix it. I used the info from this site; http://www.geeks3d.com/20130905/exploring-glsl-normal-visualizer-with-geometry-shaders-shader-library/ diffuse_shownormals.zip

I've taken a look at the terrain.shader that comes with Leadwerks to see if I can modify it to my needs, but I'm not sure where to start. What I want is to texture a grid mesh of a terrain with multiple textures based and height and slope, and maybe even an alpha map. If someone is able to point me in the right direction or even a small snippet of code that shows how the height and slope can change where a texture is shown I'd appreciate it. Thanks.

I'm currently trying to subdivide a triangle in the geometry shader. I put the material using the shader on a plane made from two triangles. However it seems that the coordinates in GLSL are different to that in Leadwerks? That the positive X axis in Leadwerks is actually the negative X axis in the shader. And the same for the Z axis. The Y axis seems fine. I want the shader to turn the plane of two triangles into a more detailed grid for a terrain. I know the shader works on each triangle, so I will have to divide each triangle itself into the appropriate triangles so that the end result in game looks like a uniform grid. I've thought of tessellation but I don't think it'll give me the results I'm looking for. Any help with this is appreciated. Thanks.

I just finished uploading the framework so that some friends can help out with the content and scene. I already have the overall theme and game put together, I just have to make them, and in this case get help with converting models, creating materials, and so forth. The framework is going extremely well. I've been working on it more than I should be to be honest but I did spend most of the day on the important matters. Plus it's Sunday for crying out loud. Anyways, I've changed several things about the framework. Here is a brief overview: Configuration is now available in the engine. This provided the gateway to the rest of the features I had plan for the framework, such as key/mouse binds, and generic configuration information for both the "engine" and "game." The key/mouse bind configuration file looks similar to: forward=w backward=s left=a right=d jump=space leap=lshift+space crouch=c | toggle fire=leftmouse aim=rightmouse grenade_toss=middlemouse | release grenade_cook=middlemouse debugphysics=f6 | toggle use=e It's fairly straight forward but the configuration file can contain basic instructions, such as "release" and "toggle." The configuration class itself provides the rest of the support. Examine the following, which is now accessible to Lua: if input:hit("leftmouse") == 1 then -- fire logic end if input:hit(input.get("use")) == 1 then -- use logic end if input:toggle("crouch") == 1 then -- do crouch end The engine configuration is managed with: config.get("resx") The game configuration is managed with: game.get("difficulty") One last feature I've added is a way to change between behaviors. These behaviors are strictly Lua, a hybrid, and strictly C/C++/C#/BlitzMax. If you provide the file "engine.lua" into the root of the project, the framework will only execute that LUA file after creating the graphics context and managers (config, input, game, etc.). The "hybrid" is a mix of the two. The framework calls upon specific Lua files at specific times. They could be looked at like "hooks." The Lua files are located at: "/scripts/dice" Examples are "update.lua" and "flip.lua." The framework also now handles scenes. It allows Leadwerks to process the scenes at the moment but then each entity in the scene to turn into an actor by the framework. This way you can get any actor: local actor = engine:getactor("myEditorAddedActorName") actor:translate(vec3(0,0,0)) actor:setkey("health", 20) Actors have their own Lua files and due to the structure described above we should be able to swap Lua files on the fly. The plan I will be attempting is similar to the following: local actor = engine:getactor("myactor") actor:setscript("newscript.lua") actor:runscript() I assume it will work, but who knows. Since per entity/actor scripts work the flexibility with the framework is fairly polished. I'm starting on default controller mechanics, soon to get into third person characters, and so on. Once my buddies can help me out I'll have more to test mechanics. Everyone should also check out Scarlet Thread Studios work, it looks to me like an RTS/TPS style framework, similar to Diablo series. Slight modifications can turn that into an RTS, FPS/RTS, and so on. Same with Pixel Perfect's engine Neutrino, which utilizes EKI One, and is turning out fantastic. I've bugged him to lease it but he isn't budging. Sorry everyone, lol. Just playing, Pixel. MG, always awesome work. Thanks for joining up to help with the content. Macklebee, hoping you'll come aboard and help me out with Lua. I'm really not in the mood to fully learn Lua at the moment. I plan to stick with hard-coded mechanics, lol. Read the above, it explains how to force the framework to let Lua control the main loop. Figured that would be your expertise. Awesome hangout session. I never planned to make it, thought it was out of my schedule, so it was kind of unexpected, lol. I had to register with Google+ and everything. It was fun, meant to talk about more, and to everyone else instead of just Josh, but I had to go AFK; turned out to be too long. I hope I'm invited to the next hangout but I don't have a camera. Thanks for reading.

There are several here who already know me, but for those who don't, my name is Paul Thomas. I've been programming for a long time now; I started when I was 16 (I'm now 30) with HTML, CSS, Javascript, and CGI/Perl. Hell back then there wasn't a lot of people who even used the internet at home, lol. At least in my area, I'm sure others, especially in California, were a lot further ahead at that time in terms of technology and the interest in the technology. Through the years I've learned multiple languages from strictly web-based to software based. My interest in computers when I was 16 was to make a game, but at the time I thought it would have been much easier to prototype the whole idea in a web-based browser game. I had completed the browser game, which was the original "Eternal Crisis," and worked nicely. My plan was to update the entire web-based system, polish everything, and officially advertise (I had invited friends to play the game). That's when I learned about a "fried hard drive" and eventually learned about "backup" and how to install a hard drive. Those whom already know me, know what Eternal Crisis is, and my Blogger shows some of the history on that project. I had taken that project, along with another, over to Unreal Engine 3 because it best suit the project. Along the years of learning that engine I was using LE for prototyping ideas and so forth. While I'm not working on my own engine (temporarily titled "3D Dice"), FPS/RPG framework for UE3, or R.A.T.S., I work on my framework for Leadwerks Engine 2.5. I've never shared this framework before, in fact it always felt like I had to pull it out of a shallow grave each time I added to the framework design and programming. I'm a notebook junkie, I plan out mechanics, structures, and so forth on paper, before going over to digital. Old habbits that die hard I guess. Now I felt like sharing the progress, which isn't a lot, but it's a great start to me. It's a great start to me because it actually runs, lol. The state of the framework isn't even close to the final planned and written design, but progress is progress. Always move forward until it's finished, even if you can only pick that project up once every two weeks (by then I/you should probably take a look at your workload and fix it instead of attempting such project schedules; however this isn't vital to me and rates low on my importance scale), if it's updated then progress is moving forward. This is also harder to work with if you don't plan your software before actually programming (unless it's routine for you with available libraries for shortcuts in development). As most programmers should know, the programmers "update" isn't as glamorous as an artists "update" as it's not about visual stimulation but overall program/software flow. In the case of my LE framework (obviously untitled) it's all about providing mechanics and how that is achieved is important especially in the case of LUA access and how everything works together; from configuration/data management, to input binding, and all the way down to AI. Until occupied again by my other tasks I will eventually share the entire framework structure and I will always be showing examples of syntax; cause that's what programmers do. Just to clear the obvious questions that may come from the community: Q) Do I plan to give away code, the framework, and be an open source kind of person? A) No, not really. First of all, you would have to wait, to anyone else at the moment the framework is as useful is a partially finished library. How long you would have to wait would depend on how much time I can spend on the framework and in all honestly it's not much at all (read above, and actually read). Q) Do I plan to sell or lease the framework? A) No, don't think so. I even think that's against Leadwerks terms since it could be deemed an "FPS Creator," which is definitely in the terms. Q) Is my framework really that great? A) Nah, I mostly ramble, and I'm actually writing this to share with long time friends here at Leadwerks. Some won't even visit anywhere else to communicate because they are so used to using Leadwerks for that; it is indeed where we all met. Q) Who are my friends? A) I have none, it was a lie. Now, about this framework. This "framework" isn't the same, exactly, as the framework that comes with LE. The framework that comes with LE handles some dirty work for you when it comes to creating the worlds, cameras for those worlds, shader effects, and helper functions. The framework I'm designing is technically similar to a game engine. I personally consider Leadwerks Engine as a rendering API with physics and this framework uses that rendering API and provides mechanics. The mechanics the framework provides is what makes up the detail of the framework. INI SQL Application Graphics Game The above are considered "managers" in that they only handle what they should be managing. The "INI" only works with INI files, such as a configuration manager. The "SQL" only works with SQLite3, providing helper functions for easier SQL management, and so forth. There are more planned managers than the above, but these are what are completed in terms of programming. The only real interesting portion to discuss about the framework is within the "Game" manager itself. The game manager provides two special classes/managers; "Object" and "Actor." Actor inherits everything about an Object. What defines an Object is a game entity that is never interacted with by the player. Objects are useful as it can be used for multiple purposes without consuming a lot of resources for each "component" or "plugin" I'd like to add onto the framework. For example, a Timer would be an Object. You don't interact with a Timer in a game, but there is a timer running in the background. Example: class ETimer : public EObject { public: ETimer(void); virtual ~ETimer(void); void Initialize(void); void SetTimer(float StartTime); void StopTimer(); }; While working with the framework you would do something similar to: // EGame::EObject // EGame::Objects EObject Objects; // .. ETimer Timer; Objects.Add("Timer", Timer); // .. ETimer Timer = Objects.Get("Timer"); Timer.StartTimer(0.0); // .. Timer.StopTimer(); // inherited by EObject Timer.Unload(); An Actor inherits everything that defines an Object. The difference between the two is that an Actor is something that a player could see, hear, interact with, or can move, rotate, and so forth. If you can see how this is all going, everything starts extending the Actor, such as the character, weapon, or items. Here are some examples of working with Actors in the framework: // EGame::Actors Actors.Add("oilbarrel", "oilbarrel.gmf"); // .. Actors.Rotate("oilbarrel", vec3(10.0f, 0.0f, 10.0f)); // .. Actors.Translate("oilbarrel", vec3(10.0f, 0.0f, 0.0f)); // .. EActor barrel = Actors.Get("oilbarrel"); // rotate with interpolation barrel.Rotate(vec3(1.0f), 0.1f); barrel.Translate(vec3(0.0f, 1.0f, 0.0f), 0.1f); // .. EActor Barrel; // new name Barrel.Name = "barrel01"; // new mesh Barrel.LoadMesh("oildrum.gmf"); Actors.Edit("oilbarrel", Barrel); A quick overview of an Actor: //EActor ID Name Tag Parent Location Rotation Mesh Sounds Particles Each Actor can also have children which are also Actors. This provides another version of parent/child relationships but also provides additional benefits which will be discussed in later blogs. The ID and Name variables are provided by Object and the Object provides more variables, but is listed for importance. When creating an Actor it is automatically tagged for unique identification. In the above example "oilbarrel" is actually stored as "oilbarrel_0" and simply incremented for each Actor that is created. This is identified by the Actors "Tag". The "Name" variable is a forced name, therefore searching for an Actor by the name, with more than one Actor having the same name, the first result is returned. Actors will be automatically created properly for each entity in a scene. The framework will be using a custom scene manager and handles initial Actor creation. Programmers/Scripters can then add to the Actors list with C++ or LUA like the above examples. class MyGame : public EGame { public: void Load(void); void Update(float DeltaTime); // .. void MyGame::Load(void) { Actors.Add("custom_actor", "mymesh.gmf", "force_tag_name"); EActor actor = Actors.Get("custom_actor"); EActor actorCopy = Actors.GetTag("force_tag_name"); actor.Translate(vec3(0.0f)); } void MyGame::Update(float DeltaTime) { EActor actor = Actors.Get("custom_actor"); // interp move with speed and threshold option actor.Move(vec3(10.0f), 1.0f, 1.0f, 0.35f); } }; In upcoming blogs, when I do get the time, I'll post up some videos. Those selected for the invite only alpha testing will get their information on how to use the framework. Friends of mine that didn't get an invite and are interested in alpha testing please private message me; I most likely didn't send you the information because I figured you were busy with your own project(s). Well, out of time. Thanks for reading.

I apologize preemptively for the title. So I picked up a Samsung Galaxy Tab today, for testing...yeah, that's it, "testing"... I installed the USB driver for Windows, restarted my computer, and was able to start debugging Leadwerks3D on it with no trouble at all. However, the rendering showed black objects that ought not be black. At this point in the game, having such a basic issue is very scary to me. I tracked the problem down to the lighting uniforms being passed to the shader, but something didn't make sense. In GL Shading Languages (GLSL), you can have arrays of uniforms, like this: vec3 mediump lightdirection[4]; A uniform array like this should be accessible from the main program by setting individual elements in the array, or by setting the entire array at once with a pointer to eight floats. See for yourself: http://www.khronos.o...spec_2.0.25.pdf Page 35: It did not appear that the light color and direction was being sent correctly, and more detailed debugging confirmed this. After a few hours of testing, I finally determined that uniform array names on iOS have end with '[0]' (I didn't test any other element indexes, at least on the iOS simulator. My provisioning profile just expired, and that's a whole other story...), and just setting the uniform array at once with the name will not work. On the Samsung Galaxy Tab, the situation is reversed. My HTC Evo is the only device that follows the OpenGLES specification and allows either. Samsung Galaxy Tab: "lightdirection" iOS: "lightdirection[0]" Evo: "lightdirection" or "lightdirection[0]" (as it should) The solution? I'll just avoid using uniform arrays on any mobile devices. It's not hard to avoid now that I know what to look for, but it's hell figuring out which parts of the GL spec the driver authors ignored. Fortunately, you don't have to worry about any of that, so you can just make your games and be happy.