Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

8,158 Excellent

About Josh

Profile Information

  • Gender
  • Location
    San Francisco, CA

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. @Rick Maybe because models have to be created without UV seams or cracks in displacement will appear. I am adding a displacement vertex value so that displacement can be pulled in along UV seams. I see tessellation being a common thing in two areas: terrain and brushes. With brush geometry I can add some extra vertices so that displacement gets tucked in along the edges and you never have to worry about it. It's common for PBR materials to include a displacement map so I think tessellation will be much more common in Turbo. Perhaps a script tool can also be created that detects UV seams and sets those vertices' displacement to zero.
  2. Josh

    Lighting Problem

    Very strange. Can you post the contents of smoke.mat?
  3. Unfortunately this feature does not work well when additional shader stages are added to the file: https://community.khronos.org/t/how-to-create-single-file-spir-v-shaders-for-vulkan/104078
  4. Along the way I discovered problems with single-file SPIR-V shaders when you start adding tessellation stages into the mix: https://community.khronos.org/t/how-to-create-single-file-spir-v-shaders-for-vulkan/104078 So I have reverted to having a separate SPV file for each stage.
  5. Now that I have all the Vulkan knowledge I need, and most work is being done with GLSL shader code, development is moving faster. Before starting voxel ray tracing, another hard problem, I decided to work one some *relatively* easier things for a few days. I want tessellation to be an every day feature in the new engine, so I decided to work out a useful implementation of it. While there are a ton of examples out there showing how to split a triangle up into smaller triangles, useful discussion and techniques of in-game tessellation is much more rare. I think this is because there are several problems to solve before this technical feature can really be made practical. Tessellation Level The first problem is deciding how much to tessellate an object. Tessellation should use a single detail level per set of primitives being drawn. The reason for this is that cracks will appear when you apply displacement if you try to use a different tessellation level for each polygon. I solved this with some per-mesh setting for tessellation parameters. Note: In Leadwerks Game Engine, a model is an entity with one or more surfaces. Each surface has a vertex array, indice array, and a material. In Turbo Game Engine, a model contains one of more LODs, and each LOD can have one or more meshes. A mesh object in Turbo is like a surface object in Leadwerks. We are not used to per-mesh settings. In fact, the material is the only parameter meshes contained other than vertex or indice data. But for tessellation parameters, that is exactly what we need, because the density of the mesh polygons gives us an idea of how detailed the tessellation should be. This command has been added: void Mesh::SetTessellation(const float detail, const float nearrange, const float farrange) Here are what the parameters do: detail: the higher the detail, the more the polygons are split up. Default is 16. nearrange: the distance below which tessellation stops increasing. Default is 1.0 meters. farrange: the distance below which tessellation starts increasing. Default is 20.0 meters. This command gives you the ability to set properties that will give a roughly equal distribution of polygons in screen space. For convenience, a similar command has been added to the model class, which will apply the settings to all meshes in the model. Surface Displacement Another problem is culling offscreen polygons so the GPU doesn't have to process millions of extra vertices. I solved this by testing if all control vertices lie outside one edge of the camera frustum. (This is not the same as testing if any control point is inside the camera frustum, as I have seen suggested elsewhere. The latter will cause problems because it is still possible for a triangle to be visible even if all its corners are outside the view.) To account for displacement, I also tested the same vertices with maximum displacement applied. To control the amount of displacement, a scale property has been added to the displacementTexture object scheme: "displacementTexture": { "file": "./harshbricks-height5-16.png", "scale": 0.05 } A Boolean value called "tessellation" has also been added to the JSON material scheme. This will tell the engine to choose a shader that uses tessellation, so you don't need to explicitly specify a shader file. Shadows will also be rendered with tessellation, unless you explicitly choose a different shadow shader. Here is the result: Surface displacement takes the object scale into account, so if you scale up an object the displacement will increase accordingly. Surface Curvature I also added an implementation of the PN Triangles technique. This treats a triangle as control points for a Bezier curve and projects tessellated curved surfaces outwards. You can see below the shot using the PN Triangles technique eliminates the pointy edges of the sphere. The effects is good, although it is more computationally expensive, and if a strong displacement map is in use, you can't really see a difference. Since vertex positions are being changed but texture coordinates are still using the same interpolation function, it can make texture coordinates appear distorted. To counter this, texture coordinates would need to be recalculated from the new vertex positions. EDIT: I found a better algorithm that doesn't produce the texcoord errors seen above. Finally, a global tessellation factor has been added that lets you scale the effect for different hardware levels: void SetTessellationDetail(const float detail) The default setting is 1.0, so you can use this to scale up or down the detail any way you like.
  6. I found another optimization that I think will pretty much eliminate slowdown when shadows are redrawn.

  7. Two and a half months later, we have shadow maps working:
  8. I’m not sure, I will have to experiment with it.
  9. @gamecreator If you are asking about shadows on vegetation, there is no vegetation system currently, so that problem is solved. Variance shadow maps don't work without all objects casting shadows so I think this will be in there.
  10. @awgsknite This is supported as of LE 4.6.
  11. I love watching these videos.
  12. Shadow maps are now supported in the new Vulkan renderer, for point, spot, and box lights! Our new forward renderer eliminates all the problems that deferred renderers have with transparency, so shadows and lighting works great with transparent surfaces. Transparent objects even receive lighting from their back face automatically! There is some shadow acne, which I am not going to leave alone right now because I want to try some ideas to eliminate it completely, so you never have to adjust offsets or other settings. I also want to take another look at variance shadow maps, as these can produce much better results than depthmap shadows. I also noticed some seams in the edges of point light shadows. Another interesting thing to note is that the new renderer handles light and shadows with orthographic projection really well. A new parameter has also been added to the JSON material loader. You can add a scale factor inside the normalTexture block to make normal maps appear bumpier. The default value is 1.0: "normalTexture": { "file": "./glass_dot3.tex", "scale": 2.0 } Also, the Context class has been renamed to "Framebuffer". Use CreateFramebuffer() instead of CreateContext().

    1. gamecreator


      Congrats on the progress!  Looking forward to some screenshots.

    2. Josh
  14. Okay, I now have all the Vulkan knowledge I need to finish the renderer.

  • Create New...