Josh

It's got to be a driver bug, or some obscure GLSL rule I don't know about. If I isolate one stage the shadowmap looks fine. It looks to me like there is a problem when the texture that is used in a lookup is not the same across near neighboring pixels...

I did some more testing and it looks like it might be a memory barrier issue, maybe. The pattern that appears looks similar to another problem I saw in post-effects, but I don't think the directional light shadow stages are all rendering each frame. You can see here the divisions between stages are clean.

Update is up now that saves probe renders in the map file. Static lib is not updated yet, but you can reload the map in the editor and see it working.

Can confirm. In fact they weren't working at all, but I am uploading a fix for that right now. I need to decide how to handle saving and loading of probe reflections, or whether they should just be re-generated at load time.

Here it is working in the editor, with terrain. I had to make a fix because the volume height was being used for the agent height. This seems to be working correctly. If there is no more specific complaint I will mark this resolved.

Stupid me...you have to press D in the example to show the nav mesh.

The example here works correctly, but I noticed that navmesh->SetDebugging(true) does not display a visible mesh: https://www.ultraengine.com/learn/CreateNavMesh?lang=cpp

The big change in the navmesh creation was that you now need to explicitly specify the number of tiles and voxels per tile. Before you inputted the overall size and voxel size, and it calculated the nearest power-of-two tile resolution. But this caused a lot of problems because not all values you could enter were valid, so integrating this into the editor was ugly because the user could input invalid values.

What was happening is the logic for retrieving string values from entities just wasn't in there, so string properties would just remain whatever their last value was.

If I isolate each stage in the shader, each one displays fine. I think this is an error in the driver. Added this to PBR/Lighting.glsl at line 269: if (index != 1) return lighttype;

From the docs: Modeling Shapes Sometimes we need finer control over physics shapes. Fortunately, it's easy to build shapes into a model and have them load automatically in Leadwerks. To do this, just add a limb in your modeling program and set the name to "collisionhull". This limb will be turned into a physics shape when the model is loaded. If you want to build a polygonal mesh collision shape, just create a limb in the model named "collisionmesh". Remember, a poly mesh collision shape does not react to physics forces, so this is good for making a low-poly collision shape for a building or other large stationary object. You can also use multiple objects in the model file to build a compound shape made of multiple pieces. If you are making a compound collision shape, it is perfectly okay to name the separate limbs "collisionhull01", "collisionhull02", etc., since Leadwerks just considers the first part of the name.

Should be fixed now. You might need to sync your project to get a new shader.

Fixed

Added this.

Vertices do not snap to the grid. Movement of vertices and objects is in increments of the grid size. This is by design. A separate "snap to grid" menu item might be in order.

Updated static library with recent fixes.

I'm not sure what it is, but its not the ambient light setting actually. I am going to lock this thread now. If something else comes up please tell me.

Oh, okay it just looks like the ambient light is not being saved in the game save.

Okay, it was a simple fix. I also notice the green block gets a little darker upon reload, but I don't know why yet.

I did some fine-tuning and I believe the issues are fixed in the editor glTF save feature. Properties that are only supported by Ultra get saved in the glTF material "extras" field.

The color intensity is a value that gets calculated from the color, and saved back as the color. It won't appear separately in the glTF file. For example, if the material color is (2, 1, 1, 1) then the intensity in the editor will show 200 and the color will be displayed as (1, 0.5, 0.5, 1). Although Ultra treats alpha blending and alpha masking separately, in the glTF format they are two different settings for the alphaMode value, so they cannot both exist in the same material in a glTF file. (This is fine, as you would never want to use them together.)

Fixed bug that caused editor to save bad / invalid glTF files when mesh tangents are present.

working on it...

Updated the static lib with all recent fixes.

I have not started on any vegetation system in Ultra. The rendering is so fast that a special system for vegetation might not be needed at all, except in the case of very large environments. But in any case, the Lua and C++ APIs are much better synced together in Ultra than in Leadwerks.