Jump to content

Website refresh and Leadwerks 5

Josh

5,911 views

vr_main.jpg.35954ceccc3a0ff84cb31c21c99541bf.jpg

Back around February I started working on a website update that included the following:

  • Responsive design everywhere.
  • SSL everywhere.
  • Visual improvement of website.
  • Updated documentation system.
  • Tutorials for C++ programming basics.
  • Update forum software to new major version.
  • Forum moved to new URL.

All of that is now pretty much done.  These changes improve the online Leadwerks experience and are independent from the software itself, so it was a good idea to get them done now.

Since September I've had more time to think about Leadwerks Game Engine 5, and although I am not completely sold on Vulkan, I think it's a good plan.

Leadwerks 5 is all about performance and user experience with VR as a prime target.

Multithreaded Architecture

Separate threads for navmesh updating, physics, game logic, culling, and rendering.  The rendering thread loops at a constant 60 or 90 (for VR) frames per second regardless of what your game is doing.  This gives your game logic four times more time to run, while independently maintaining a constant framerate.  The design I have in mind will make Leadwerks 5 the fastest game engine, ever, and choosing Leadwerks for VR will be a no-brainer.

Leadwerks Editor 5

A new editor will be written in C++ using Leadwerks GUI, which will give us the same appearance on Windows, Linux, and Mac.  Functionality will be pretty close to the existing editor, but with more room to grow and a few improvements.  Because it's written in C++ parts of the editor can be exposed to Lua, and an editor API will be provided for making Lua mods and plugins.  By default, it will use a dark theme to be easy on the eyes.  A standalone script editor may be provided as well.

PBR Material System with Substance Support

The lighting model will use a more advanced lighting equation and substance PBR materials (metalness and roughness) will be loaded natively.

Shared Pointers

The reference counting system in the Object class will be replaced with C++11 shared pointers.  This gives you the performance of C++ with ease of use like a garbage-collected language.

64-bit

The engine and editor will be released as a 64-bit build only.

Game Templates

More game templates will be provided.  Fortunately we can add these now and updates for Leadwerks 5 will be minimal.

Open-Source Components

Source code to some parts of the engine and editor may be provided on the Leadwerks GitHub account.  For example, I may make a standalone open-source script editor or publish some of the engine classes for the community to play with.

Platforms

Leadwerks 5 will launch on Windows, Linux, and Mac.  The improved compatibility of Leadwerks 5 means we could do crazy things like run the editor on an iPad, but I'm going to stick with what I know sells.

Enterprise Edition

A standalone version that does not use Steam will be sold in bundles to companies that require this.

Pricing

A monthly plan may be introduced at around $5-20 per month.  Pricing for a perpetual license for the standard and pro editions would most likely be the same as now ($99-199), with a discount for early adopters / upgrades.  The enterprise version would probably be about $1000 per seat with a discount for schools.

If you found this blog interesting, please consider using the social media share buttons below to share it.



52 Comments


Recommended Comments



That is a lot of good news! Got a few questions/remarks:

  1. Why 64 bit only and no more 32 bit? I know most players have a 64 bit machine, but is it hard to maintain a 32 bit version as well?
  2. Will we be able to make our own threads? Currently the Leadwerks::Thread function doesn't allow me to bind class functions. I'd like to make one for things like networking and AI.
  3. I really like the smart pointer integration. Was one of the few things that I felt missing.
  4. Plans for Leadwerks after the 5.0 release? VR optimization or also some other topics you want to tackle?
  5. Plans for the Leadwerks Game Launcher? C++ games support?
  6. Is the App.h/cpp going to be removed, where main.cpp will now be the base of your project?
  7. Leadwerks 5.0 when? :)

I really like all of these changes. Going into the right direction. I'll be one of the early adopters!

Share this comment


Link to comment
1 minute ago, Evayr said:

That is a lot of good news! Got a few questions/remarks:

  1. Why 64 bit only and no more 32 bit? I know most players have a 64 bit machine, but is it hard to maintain a 32 bit version as well?
  2. Will we be able to make our own threads? Currently the Leadwerks::Thread function doesn't allow me to bind class functions. I'd like to make one for things like networking and AI.
  3. I really like the smart pointer integration. Was one of the few things that I felt missing.
  4. Plans for Leadwerks after the 5.0 release? VR optimization or also some other topics you want to tackle?
  5. Plans for the Leadwerks Game Launcher? C++ games support?
  6. Is the App.h/cpp going to be removed, where main.cpp will now be the base of your project?
  7. Leadwerks 5.0 when? :)

I really like all of these changes. Going into the right direction. I'll be one of the early adopters!

  1. 32-bit operating systems are pretty rare nowadays (about 6% of Windows users): http://store.steampowered.com/hwsurvey/
  2. You can make your own threads right now.  You can pass an object to the thread and call its functions.  Do you have any suggestions on how to improve this?  I don't expect the user to do a lot of multithread programming because it's really hard and if I set mutexes for every command it would end up being just as slow as a single thread.  But yeah, networking is one example where it is appropriate.
  3. Leadwerks 3 began development before C++11 was available, so it was never designed for shared pointers.
  4. After? :huh:
  5. Game Launcher has been stalled because I need to improve the way game thumbnails are loaded.  Right now it pauses while the entire collection of games has their thumbnails downloaded, resized, and cached.  Leadwerks GUI needs to be completed for this as well.
  6. App class and script are being removed in 4.4.  Docs are already updated.
  7. When it's done.  Maybe another Kickstarter should be done for this?

Share this comment


Link to comment

Oh yeah, I don't see Game Launcher supporting C++ games in the future.  With Steam Direct you may not even need this, unless it is just a way to get your game in front of more people.  I'm not sure how Steam Direct will affect things, if it ever happens.

Share this comment


Link to comment

Unlike updates to version 3 and 4 Leadwerks 5 will introduce changes to the API.  However, it's not going to be a whole new engine written from scratch, more a reconfiguration of what we have.

Share this comment


Link to comment

"32-bit operating systems are pretty rare nowadays (about 6% of Windows users)"  haha so are Linux users: 0.76%.  But I'm just giving you a hard time.  I know it's different for you.

Very interesting developments.  So to be clear, Leadwerks 5 will be a separate product we need to purchase?  Will there be an upgrade option from 4 at a discount?

Share this comment


Link to comment
11 minutes ago, gamecreator said:

"32-bit operating systems are pretty rare nowadays (about 6% of Windows users)"  haha so are Linux users: 0.76%.  But I'm just giving you a hard time.  I know it's different for you.

Very interesting developments.  So to be clear, Leadwerks 5 will be a separate product we need to purchase?  Will there be an upgrade option from 4 at a discount?

There will be some kind of discount option for upgrades or possibly early adopters.

Share this comment


Link to comment

Really cool news! I've been dropping by for the past few months as the site has been slow. I like what I've read, happy that a "pay up front" option is still available, as it's one of the pluses of Leadwerks for me. Not a big fan of subscription-ware, but I understand why it's there.

A question though:

Since Leadwerks 5 is gonna be different when it comes to API, and it being a separate product than what we have now, what's gonna happen to 4.3/4.4 support? Because I suspect that the current Steam app is gonna be Leadwerks 4, and unless you request to take down the app, people might still buy and use the current version while 5 is well out. I know for 2.x, you moved all documentation to a legacy page, do you plan to do that? It's something that's not worth getting worried about; I know, just was curious on your thoughts. 

Also, is 4.4 still gonna be a thing?

I wish you the best and looking forward to the future, looking forward to your future development blogs too. I'll be happy to early-adopt when available! :)

Share this comment


Link to comment
15 minutes ago, reepblue said:

Really cool news! I've been dropping by for the past few months as the site has been slow. I like what I've read, happy that a "pay up front" option is still available, as it's one of the pluses of Leadwerks for me. Not a big fan of subscription-ware, but I understand why it's there.

A question though:

Since Leadwerks 5 is gonna be different when it comes to API, and it being a separate product than what we have now, what's gonna happen to 4.3/4.4 support? Because I suspect that the current Steam app is gonna be Leadwerks 4, and unless you request to take down the app, people might still buy and use the current version while 5 is well out. I know for 2.x, you moved all documentation to a legacy page, do you plan to do that? It's something that's not worth getting worried about; I know, just was curious on your thoughts. 

Also, is 4.4 still gonna be a thing?

I wish you the best and looking forward to the future, looking forward to your future development blogs too. I'll be happy to early-adopt when available! :)

Version 4 documentation will be moved to a folder like "learn/4" and left there, with a robots.txt file to tell Google not to cache the page.  The final version will point the user to that location.  Leadwerks Game Engine on Steam will be renamed to Leadwerks Game Engine 4 and will continue to be sold.

Version 4.4 is coming out this summer.  Mind you, we will all be using 4.x for a while.  The stuff I described here is a big task.

Version 5 will make some breaks with how 4 works, but it's not a whole new engine and the same code will work with small changes.  The two things I can think of right now are shared pointers and I want to add a "surface builder" class, and stop storing surface data in system memory.  Hooks will completely go away, as the Actor class works better for this and the editor will no longer need C-style function pointers.  Hopefully all or most Lua code will work without any changes, but I am not sure yet.  Version 4 to 5 will be much less of a jump than 2 to 3 was.

Eventually, Game Launcher will probably use both a 4.x and 5.x executable and it will just choose the right EXE to run.

Share this comment


Link to comment
11 minutes ago, Josh said:

Version 4.4 is coming out this summer.  Mind you, we will all be using 4.x for a while.  The stuff I described here is a big task.

Alright, sounds good! I was getting a feeling that the current version was gonna "rot" until you said that! Also nice to hear that 4 and 5+ are gonna co-exist in a way. 

Again, interested to see what will come, but take your time. We want the best. ;)

Share this comment


Link to comment

Does the enterprise version include source code? Or is that no longer an option? Is this also a yearly license?

I like the idea of a subscription. Granted it will cost me more overall, but I think it will allow for more updates to the engine. Would allow you to grow leadwerks better.

I'm super excited about multi-threaded support. I know asset loading is a frustration section for me as it locks up the UI.

I'm also super excited about the idea of plugins and open source support. 

As far as SharedPointers, will there be a backwards compatibility API for legacy code? My source is getting pretty large TBH, it would be difficult to replace everything to shared pointers that interacted with Leadwerks specifically. Which is why I haven't really adopted the Actor class as well.

Share this comment


Link to comment
5 minutes ago, martyj said:

Does the enterprise version include source code? Or is that no longer an option? Is this also a yearly license?

I like the idea of a subscription. Granted it will cost me more overall, but I think it will allow for more updates to the engine. Would allow you to grow leadwerks better.

I'm super excited about multi-threaded support. I know asset loading is a frustration section for me as it locks up the UI.

I'm also super excited about the idea of plugins and open source support. 

As far as SharedPointers, will there be a backwards compatibility API for legacy code? My source is getting pretty large TBH, it would be difficult to replace everything to shared pointers that interacted with Leadwerks specifically. Which is why I haven't really adopted the Actor class as well.

A source code license will be and is available, but that is a very big cost.

On my end, the subscription model is also very appealing, even if it were to make less money overall it is still better to have reliable monthly income.  I'm sure you can think of a lot of products who had the genius idea to promise their users "free upgrades for life" and are no longer around. :lol:

Hmmmm, Model::LoadASync()?

You can probably use typedefs or auto to make your code forward-compatible, but again this is still in the research phase and I can't say for sure:

auto model = Model::Box();
model->SetPosition(1,2,3);// shared pointers still act like a pointer

 

Share this comment


Link to comment
11 minutes ago, Josh said:

On my end, the subscription model is also very appealing, even if it were to make less money overall it is still better to have reliable monthly income.  I'm sure you can think of a lot of products who had the genius idea to promise their users "free upgrades for life" and are no longer around. :lol:

As long as you keep the full price option, I'm all for the addition of a subscription option. :)

Share this comment


Link to comment

I am all ears about extending the editor with plugins/mods. Will this allow us to create our own windows/tabs, run scripts in the editor? 

The lack of ability to extend the editor is the most important reason for me to not use Leadwerks for any large project and just mainly to try stuff out. That could be a real game changer.

As for the standalone script editor, ever had a look at Visual studio code? Crossplatform, lightweight, easy creation of custom tools etv. With the current documentation system you could generate a plugin for visual studio that lets you create an entire intellisense for Leadwerks + Lua.

Share this comment


Link to comment
3 minutes ago, AggrorJorn said:

I am all ears about extending the editor with plugins/mods. Will this allow us to create our own windows/tabs, run scripts in the editor? 

The lack of ability to extend the editor is the most important reason for me to not use Leadwerks for any large project and just mainly to try stuff out. That could be a real game changer.

As for the standalone script editor, ever had a look at Visual studio code? Crossplatform, lightweight, easy creation of custom tools etv. With the current documentation system you could generate a plugin for visual studio that lets you create an entire intellisense for Leadwerks + Lua.

People love plugin systems when they first come out and hate them when an update makes all their plugins incompatible..  So keep in mind there are limitations to how useful they can be.  I am not 100% sure how it will work, but an editor API would allow Lua to add new windows and stuff, I think.

I would probably use the same code in the main editor and just separate it out for the standalone.  This is still going to use Scintilla, but Scintilla with C++ is much simpler than trying to make it run with BlitzMax.  It's really a miracle @klepto2 was even able to figure that out.

Share this comment


Link to comment

Be careful with that many threads! but is there any specific reason you decided against Vulkan? What parts of the rendering do you plan on letting threads handle with OpenGL? i never knew there was effective ways of threading in GL.

For example in a Vulkan implementation, you'd do something like allow all available threads to generate secondary command buffers for the meshes in the scene, then execute a primary command buffer when all the secondary cmd buffers have been generated.

You really should profile a lot before starting to multithread that heavily, if you look at the update, and render time in Leadwerks... the update time is generally nothing. The render time is what's killing us.

Share this comment


Link to comment
6 minutes ago, Crazycarpet said:

Be careful with that many threads! but is there any specific reason you decided against Vulkan? What parts of the rendering do you plan on letting threads handle with OpenGL? i never knew there was effective ways of threading in GL.

For example in a Vulkan implementation, you'd do something like allow all available threads to generate secondary command buffers for the meshes in the scene, then execute a primary command buffer when all the secondary cmd buffers have been generated.

Culling and rendering will be separate threads.  One will gather up batches of surfaces to be rendered, and the other thread will continuously rendering them.  This is basically how command buffer APIs work, as I understand it.  I don't think Vulkan will offer a big performance increase over the architecture I have in mind.  It's only AMD cards that get a significant boost, and OpenGL is still the only cross-platform graphics API for Windows, Mac, and Linux.

The niche-ness of Vulkan does not make me feel good about the drivers.  The only game I have that supports it crashes a lot (Doom).  There's just not enough there to make me want to jump on that bandwagon yet.

Share this comment


Link to comment

All cards get a big boost in Vulkan when you implement a multi-threaded renderer... Vulkan lacks any global states and allows for a command pool to contain command buffers on separate threads. Because of this the threads never have to wait behind a lock to wait for access to some data to become available.

That being said, OpenGL is much much easier to implement and it is certainly fast enough. Your idea is definitely a good one too for the culling & rendering to be in separate threads. Still though it is no match for Vulkan and what you can do with it. Keep in mind Khronos designed Vulkan with multithreading and VR as the primary goal. A programmer can make a renderer with Vulkan that never locks a mutex by simply having 1 (or 2) command pools per thread.

Sounds like some good ideas though, excited to see what you come up with.

 

Edit: I don't think it's fair to say Vulkan is a niche... Khronos made Vulkan as a successor to OpenGL solely for the purposes of multi-threading and VR because OpenGL just simply isn't capable of allowing so much of the work to be handled by separate threads.

However, the drivers are certainly still young... but I mean OpenGL has been around for so long of course the drivers will be better and more stable, this will come. Vulkan is here and here to stay. Still though, OpenGL is evolving every day and more than capable of creating high performance games.

Share this comment


Link to comment

Looking forward to Leadwerks 5 :) ... some questions though:

1. Can you use Leadwerks GUI in your game or will it only be for the editor?

2. Will Windows, Linux, and Mac support be released at the same time? 

Thanks for the update

Share this comment


Link to comment
7 minutes ago, Einlander said:

Is the gmf/mdl file format going to continue?

No reason to change that. :)

1 minute ago, codeape said:

Looking forward to Leadwerks 5 :) ... some questions though:

1. Can you use Leadwerks GUI in your game or will it only be for the editor?

2. Will Windows, Linux, and Mac support be released at the same time? 

Thanks for the update

  1. Leadwerks GUI is being developed for version 4.4.  It works in a 3D graphics context or directly on a window using OS drawing commands.  I had to dig deep into XRender to figure it out.
  2. Yes.  (The editor will be a big improvement for Linux users especially.)

Share this comment


Link to comment

Oh yeah, and all models, prefabs, maps, physics shapes, textures, materials, shaders, and post-processing effects will still work just fine with no changes.

Share this comment


Link to comment

It is cross-platform totally... Khronos group doesn't make claims just to make them. They did an amazing job with OpenGL and an even better one with Vulkan. It's advantage over DX12 is the cross-platform nature. However, DX12 is probably faster because it's single platform support allows them to take advantage of windows only features to give games that little boost.

Vulkan's still young and not ready to replace anything yet. I certainly would not make an engine with it right now.as the drivers are very young. That being said support for Vulkans growing faster than anyone thought, noone thought Intel would release drivers til 2018, they came out in 2016.

That being said it is certainly a better idea to make the engine on OpenGL because Vulkan isn't "mature' yet. The day it is ready you can always make a renderer then. All I'm saying is you can't dismiss the purpose of Vulkan, it solves every problem that limits OpenGL on modern hardware and was improved/added to by many of the biggest name game companies in the world including Valve, Blizzard, Microsoft, Unity, Oculus, HTC, and hundreds of others. These people know what problems we face today, and how to solve them!

Out of curiosity do you plan on using OpenGL's newly supported direct state access? Seems like you could make things a lot faster not having to bind/change global states all the time.

Share this comment


Link to comment

A lot of those guys jump on anything new just so their name can be associated with it in case it works out.  They also said OUYA was the future and we were all going to be playing game consoles that were made out of a thumb drive.

Notice there are no Vulkan-exclusive games in existence.  It's always just an experimental feature people add on to another renderer.

Microsoft has a solid working API that reliably does everything Vulkan does, except run on Linux, and Apple is not interested in Vulkan.  So really I would say DX12 is the future for a long time.  We will see.

Share this comment


Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Blog Entries

    • By Josh in Josh's Dev Blog 4
      I have been working on 2D rendering off and on since October. Why am I putting so much effort into something that was fairly simple in Leadwerks 4? I have been designing a system in anticipation of some features I want to see in the GUI, namely VR support and in-game 3D user interfaces. These are both accomplished with 2D drawing performed on a texture. Our system of sprite layers, cameras, and sprites was necessary in order to provide enough control to accomplish this.
      I now have 2D drawing to a texture working, this time as an official supported feature. In Leadwerks 4, some draw-to-texture features were supported, but it was through undocumented commands due to the complex design of shared resources between OpenGL contexts. Vulkan does not have this problem because everything, including contexts (or rather, the VK equivalent) is bound to an abstract VkInstance object.

      Here is the Lua code that makes this program:
      --Get the primary display local displaylist = ListDisplays() local display = displaylist[1]; if display == nil then DebugError("Primary display not found.") end local displayscale = display:GetScale() --Create a window local window = CreateWindow(display, "2D Drawing to Texture", 0, 0, math.min(1280 * displayscale.x, display.size.x), math.min(720 * displayscale.y, display.size.y), WINDOW_TITLEBAR) --Create a rendering framebuffer local framebuffer = CreateFramebuffer(window); --Create a world local world = CreateWorld() --Create second camera local texcam = CreateCamera(world) --Create a camera local camera = CreateCamera(world) camera:Turn(45,-45,0) camera:Move(0,0,-2) camera:SetClearColor(0,0,1,1) --Create a texture buffer local texbuffer = CreateTextureBuffer(512,512,1,true) texcam:SetRenderTarget(texbuffer) --Create scene local box = CreateBox(world) --Create render-to-texture material local material = CreateMaterial() local tex = texbuffer:GetColorBuffer() material:SetTexture(tex, TEXTURE_BASE) box:SetMaterial(material) --Create a light local light = CreateLight(world,LIGHT_DIRECTIONAL) light:SetRotation(55,-55,0) light:SetColor(2,2,2,1) --Create a sprite layer. This can be shared across different cameras for control over which cameras display the 2D elements local layer = CreateSpriteLayer(world) texcam:AddSpriteLayer(layer) texcam:SetPosition(0,1000,0)--put the camera really far away --Load a sprite to display local sprite = LoadSprite(layer, "Materials/Sprites/23.svg", 0, 0.5) sprite:MidHandle(true,true) sprite:SetPosition(texbuffer.size.x * 0.5, texbuffer.size.y * 0.5) --Load font local font = LoadFont("Fonts/arial.ttf", 0) --Text shadow local textshadow = CreateText(layer, font, "Hello!", 36 * displayscale.y, TEXT_LEFT, 1) textshadow:SetColor(0,0,0,1) textshadow:SetPosition(50,30) textshadow:SetRotation(90) --Create text text = textshadow:Instantiate(layer) text:SetColor(1,1,1,1) text:SetPosition(52,32) text:SetRotation(90) --Main loop while window:Closed() == false do sprite:SetRotation(CurrentTime() / 30) world:Update() world:Render(framebuffer) end I have also added a GetTexCoords() command to the PickInfo structure. This will calculate the tangent and bitangent for the picked triangle and then calculate the UV coordinate at the picked position. It is necessary to calculate the non-normalized tangent and bitangent to get the texture coordinate, because the values that are stored in the vertex array are normalized and do not include the length of the vectors.
      local pick = camera:Pick(framebuffer, mousepos.x, mousepos.y, 0, true, 0) if pick ~= nil then local texcoords = pick:GetTexCoords() Print(texcoords) end Maybe I will make this into a Mesh method like GetPolygonTexCoord(), which would work just as well but could potentially be useful for other things. I have not decided yet.
      Now that we have 2D drawing to a texture, and the ability to calculate texture coordinates at a position on a mesh, the next step will be to set up a GUI displayed on a 3D surface, and to send input events to the GUI based on the user interactions in 3D space. The texture could be applied to a computer panel, like many of the interfaces in the newer DOOM games, or it could be used as a panel floating in the air that can be interacted with VR controllers.
    • By Josh in Josh's Dev Blog 0
      Putting all the pieces together, I was able to create a GUI with a sprite layer, attach it to a camera with a texture buffer render target, and render the GUI onto a texture applied to a 3D surface. Then I used the picked UV coords to convert to mouse coordinates and send user events to the GUI. Here is the result:

      This can be used for GUIs rendered onto surfaces in your game, or for a user interface that can be interacted with in VR. This example will be included in the next beta update.
    • By Josh in Josh's Dev Blog 4
      I started to implement quads for tessellation, and at that point the shader system reached the point of being unmanageable. Rendering an object to a shadow map and to a color buffer are two different processes that require two different shaders. Turbo introduces an early Z-pass which can use another shader, and if variance shadow maps are not in use this can be a different shader from the shadow shader. Rendering with tessellation requires another set of shaders, with one different set for each primitive type (isolines, triangles, and quads). And then each one of these needs a masked and opaque option, if alpha discard is enabled.
      All in all, there are currently 48 different shaders a material could use based on what is currently being drawn. This is unmanageable.
      To handle this I am introducing the concept of a "shader family". This is a JSON file that lists all possible permutations of a shader. Instead of setting lots of different shaders in a material, you just set the shader family one:
      shaderFamily: "PBR.json" Or in code:
      material->SetShaderFamily(LoadShaderFamily("PBR.json")); The shader family file is a big JSON structure that contains all the different shader modules for each different rendering configuration: Here are the partial contents of my PBR.json file:
      { "turboShaderFamily" : { "OPAQUE": { "default": { "base": { "vertex": "Shaders/PBR.vert.spv", "fragment": "Shaders/PBR.frag.spv" }, "depthPass": { "vertex": "Shaders/Depthpass.vert.spv" }, "shadow": { "vertex": "Shaders/Shadow.vert.spv" } }, "isolines": { "base": { "vertex": "Shaders/PBR_Tess.vert.spv", "tessellationControl": "Shaders/Isolines.tesc.spv", "tessellationEvaluation": "Shaders/Isolines.tese.spv", "fragment": "Shaders/PBR_Tess.frag.spv" }, "shadow": { "vertex": "Shaders/DepthPass_Tess.vert.spv", "tessellationControl": "Shaders/DepthPass_Isolines.tesc.spv", "tessellationEvaluation": "Shaders/DepthPass_Isolines.tese.spv" }, "depthPass": { "vertex": "Shaders/DepthPass_Tess.vert.spv", "tessellationControl": "DepthPass_Isolines.tesc.spv", "tessellationEvaluation": "DepthPass_Isolines.tese.spv" } }, "triangles": { "base": { "vertex": "Shaders/PBR_Tess.vert.spv", "tessellationControl": "Shaders/Triangles.tesc.spv", "tessellationEvaluation": "Shaders/Triangles.tese.spv", "fragment": "Shaders/PBR_Tess.frag.spv" }, "shadow": { "vertex": "Shaders/DepthPass_Tess.vert.spv", "tessellationControl": "Shaders/DepthPass_Triangles.tesc.spv", "tessellationEvaluation": "Shaders/DepthPass_Triangles.tese.spv" }, "depthPass": { "vertex": "Shaders/DepthPass_Tess.vert.spv", "tessellationControl": "DepthPass_Triangles.tesc.spv", "tessellationEvaluation": "DepthPass_Triangles.tese.spv" } }, "quads": { "base": { "vertex": "Shaders/PBR_Tess.vert.spv", "tessellationControl": "Shaders/Quads.tesc.spv", "tessellationEvaluation": "Shaders/Quads.tese.spv", "fragment": "Shaders/PBR_Tess.frag.spv" }, "shadow": { "vertex": "Shaders/DepthPass_Tess.vert.spv", "tessellationControl": "Shaders/DepthPass_Quads.tesc.spv", "tessellationEvaluation": "Shaders/DepthPass_Quads.tese.spv" }, "depthPass": { "vertex": "Shaders/DepthPass_Tess.vert.spv", "tessellationControl": "DepthPass_Quads.tesc.spv", "tessellationEvaluation": "DepthPass_Quads.tese.spv" } } } } } A shader family file can indicate a root to inherit values from. The Blinn-Phong shader family pulls settings from the PBR file and just switches some of the fragment shader values.
      { "turboShaderFamily" : { "root": "PBR.json", "OPAQUE": { "default": { "base": { "fragment": "Shaders/Blinn-Phong.frag.spv" } }, "isolines": { "base": { "fragment": "Shaders/Blinn-Phong_Tess.frag.spv" } }, "triangles": { "base": { "fragment": "Shaders/Blinn-Phong_Tess.frag.spv" } }, "quads": { "base": { "fragment": "Shaders/Blinn-Phong_Tess.frag.spv" } } } } } If you want to implement a custom shader, this is more work because you have to define all your changes for each possible shader variation. But once that is done, you have a new shader that will work with all of these different settings, which in the end is easier. I considered making a more complex inheritance / cascading schema but I think eliminating ambiguity is the most important goal in this and that should override any concern about the verbosity of these files. After all, I only plan on providing a couple of these files and you aren't going to need any more unless you are doing a lot of custom shaders. And if you are, this is the best solution for you anyways.
      Consequently, the baseShader, depthShader, etc. values in the material file definition are going away. Leadwerks .mat files will always use the Blinn-Phong shader family, and there is no way to change this without creating a material file in the new JSON material format.
      The shader class is no longer derived from the Asset class because it doesn't correspond to a single file. Instead, it is just a dumb container. A ShaderModule class derived from the Asset class has been added, and this does correspond with a single .spv file. But you, the user, won't really need to deal with any of this.
      The result of this is that one material will work with tessellation enabled or disabled, quad, triangle, or line meshes, and animated meshes. I also added an optional parameter in the CreatePlane(), CreateBox(), and CreateQuadSphere() commands that will create these primitives out of quads instead of triangles. The main reason for supporting quad meshes is that the tessellation is cleaner when quads are used. (Note that Vulkan still displays quads in wireframe mode as if they are triangles. I think the renderer probably converts them to normal triangles after the tessellation stage.)


      I also was able to implement PN Quads, which is a quad version of the Bezier curve that PN Triangles add to tessellation.



      Basically all the complexity is being packed into the shader family file so that these decisions only have to be made once instead of thousands of times for each different material.
×
×
  • Create New...