[Multipass Rendering in Leadwerks 5 beta]

I will have to experiment some more with this. Interestingly, this overlaps with some problems with 2D drawing. Now in reality there is no such thing as 2D graphics on your computer, it is always 3D graphics. I think my approach here will be to stop trying to hide the fact that 2D is really 3D even if it does not fit our conceptions of how it should be. Stay tuned...

[Multipass Rendering in Leadwerks 5 beta]

Okay, it looks like that will probably not work. The data management is just too complicated. I think a filter value will probably work best, because that can be handled easily in the culling routine.

[Multipass Rendering in Leadwerks 5 beta]

11 hours ago, Ma-Shell said:

Isn't that basically what a world is? Each camera renders only the objects that are in its world, so the world is basically a filter for the camera

I'm going to try adding a command like this:

void World::AddRenderPass(shared_ptr<World> world, const int order)

The order value can be -1 (background), 1 (foreground), or 0 (mix with current world). No guarantee yet but I will try and see how well it works.

[Leadwerks is so cozy]

4 hours ago, Slastraf said:

Well I already find it a little comedic that my comment criticizing LE game engine got removed so I cannot partake in this discussion. Honestly its kind of sad.

Since you say it is not acceptable as a professional tool, why are you here? I just received ten orders for the enterprise version from a little company called Northrop Grumman, but I guess you are the expert.

[Multipass Rendering in Leadwerks 5 beta]

1 hour ago, Ma-Shell said:

 

Isn't that basically what a world is? Each camera renders only the objects that are in its world, so the world is basically a filter for the camera

In an abstract sense, yes, but there’s a thousand more details than that. The strictness of both Vulkan and the multithreaded architecture mean I can’t design things that are “fast and loose” anymore.

[Multipass Rendering in Leadwerks 5 beta]

What might work better is to have a layer / tag system that lets different cameras have a filter to render certain types of objects.

To skip a camera, you can either hide it or set the projection mode to zero.

[Multipass Rendering in Leadwerks 5 beta]

3 minutes ago, Ma-Shell said:

You mean, because unlike the previous version the user does not directly call Render() anymore, since it is run on a different thread and thus the user can not correctly orchestrate the rendering? This should not be a problem, since in CreateCamera you can specify the world.

auto realCamera = CreateCamera(realWorld);
auto HUDCamera = CreateCamera(HUDWorld);
realCamera->setOrder(1);
HUDCamera->setOrder(2);
realCamera->SetClearMode(CLEAR_DEPTH | CLEAR_COLOR);
HUDCamera->SetClearMode(CLEAR_DEPTH);

 

There is a World::Render() command which basically says "tell the rendering thread to start using this world for rendering". So rendering two different worlds in one pass would be sort of difficult to manage.

[Multipass Rendering in Leadwerks 5 beta]

4 minutes ago, Ma-Shell said:

Would it be possible to use two different worlds for this? One "real" world and one for your HUD and then first rendering only the first world and after that rendering the HUD-world.

This would probably not be practical, because the rendering thread is so disconnected from the game logic thread.

[Leadwerks is so cozy]

People wanted a new engine so I am making a new engine. It takes years to develop these things. Just switching over to Vulkan took six months to get basic rendering working. Anyone who needs the performance and scale of the new engine is welcome to use it, otherwise I am not going to try to convince them.

I expect that right now is going to be pretty much the lowest point of engagement because we have a new technology that has been a WIP for several years and isn't ready yet. And there is going to be some change in the community because Turbo Engine has a different type of user than Leadwerks has.

[Next Steps]

@Lethal Raptor Games I think the next big feature will be to make the terrain system hierarchal. I will explain soon.

 

[Message Boxes]

7 hours ago, Marcousik said:

Is there something like this in current LE4.6 ?

No.

1 hour ago, gamecreator said:

You can do it through either Windows commands (I'm guessing Linux has equivalent) or try through the Leadwerks GUI (though I don't think it's documented still).

Linux actually does not. GTK or some other library that not all Linux installs have does do it. Which makes things more difficult.

[Leadwerks 4.7 Beta Available]

There is no global euler rotation stored. If you are setting a euler rotation in global space (and the parent is not NULL) then there is a conversion process whereby the euler is transformed into a quaternion. When you call GetRotation() with the global flag set, the rotation is extracted from the global 4x4 matrix and converted to a euler and returned.

This is the source code of the GetRotation() command:

	Vec3 Entity::GetRotation(const bool global)
	{
		if (global == true and parent.lock() != nullptr)
		{
			return Vec3(mat.GetRotation());//Mat4::GetRotation() returns a quaternion, this is then converted to a Euler
		}
		else
		{
			return rotation; //returns the local euler rotation, whatever was last set
		}
	}

Only local position, rotation, and scale values are stored, because if the object has a parent, moving the parent would invalidate all those global values and they would require constant recalculation.

Now I have set it so when rotation is set in local space, that rotation is calculated to the local quaternion, but the original rotation value you input is preserved if you call GetRotation() with the global flag set to false, or if there is no parent. I also made it so that Turn() will increment the angle on one axis if the other two axes in the turn value are zero.

But if that local euler gets recalculated for any reason or if a rotation is extracted from the matrix, it is possible for two different values to define the same rotation, like (270,0,0) and (-90,0,0).

[Leadwerks 4.7 Beta Available]

15 hours ago, gamecreator said:

Does this mean that we won't have to worry about euler/quaternion any more?  SetRotation and GetRotation will just work, without having to deal with conversions?

Can you be more specific? Eulers and quaternions will both work. Eulers are easy to visualize, and are fine for rotation on one axis (as most people will be using it) but quaternions are needed if you are making a space sim or something like that.

[Message Boxes]

And added RequestFiles() for multiple file selection.

[Message Boxes]

Also added RequestDir() and RequestFile(). It looks like the new Explorer dark theme is supported, so that tells me I don't have to worry about making a custom file dialog in the new editor.

[How infinite terrain can be implemented in Leadwerks Engine 5]

Current plan is that the terrain will not be "infinite" but it will be so big you will never reach the end.

[Multi-monitor Support]

Also added DISPLAY_VIRTUAL to get the entire virtual screen area.

[Multi-monitor Support]

-Yes.

-A monitor has a position relative to the other monitors. They all make up one big virtual screen.

-I’m not sure yet.

[Terrain in Leadwerks 5]

54 minutes ago, havenphillip said:

Would be cool if we could add a specular texture on the new terrain so as to get that after rain look or add oil spots etc.

Metalness / roughness will do this.

[Terrain in Leadwerks 5]

@martyj Currently there is a bug that randomly makes the whole terrain black. Probably texture data not being sent correctly to the GPU. I need to fix that, and I might implement directional light shadows before an update, if they don't take too much time.

[Terrain Normal Update Multithreading]

The reason four threads was less than 25% the speed of one is because some calculations were being skipped. I fixed that and the numbers are a little higher now, but still form the same curve.

[Precomputed BSP Trees and Static Meshes]

A similar technique for terrain reduced system memory by 130 mb on a 2048x2048 terrain.

[Precomputed BSP Trees and Static Meshes]

I tested a 1.5 million poly mesh and the BSP generation time was about three seconds. Not terrible given the size, but I would like to completely eliminate that annoying delay.

[Compressed Vertex Arrays]

My best guess is this yielded a 7% performance boost, across the board. I'm not going to test in detail because it takes a lot of changes to modify the vertex format.

[Compressed Vertex Arrays]

In fact, Leadwerks model files are usually measured in kilobytes rather than megabytes, so compressing those further would make very little difference in your game data size.