Josh

From MS: https://learn.microsoft.com/en-us/dotnet/api/system.io.filesystemwatcher.created?view=net-8.0

Editing a .fam file in VS Code, I do see two FILE_CHANGED events being emitted by the file system watcher.

Just installed Notepad++ and had no problems with multiple reloads when saving a post-processing fragment shader file. Let's see what happens when the next build of the editor goes up.

I added a weak pointer in the shader module (the asset) to all shaders they get attached to, and it will reattach them and update the shader automatically when the module is reloaded. Tested shader editing in VSCode and Notepad and with both those programs the asset only gets reloaded once...

Added selection toolbar item Added basic implementation of drag-select area. The volume intersection test is not exact yet. Revised the way converters work to make them more useful. I recommend deleting the FBXToglTF and ColladaToglTF scripts in Scripts/Start/Converters, if you have those files. Converters can now be enabled and disabled with settings. Everything is managed entirely in script, except for detecting files that need to be converted and emitting the convert file event.

It says that you left the conversation! I sent a new PM.

https://www.ultraengine.com/community/messenger/1685224954/

I think the type needs to be an exact match. We should determine what a bindless handle looks like on the CPU side.

Quite a lot of Steamworks is exposed already: https://www.ultraengine.com/learn/Steamworks?lang=cpp There is also support for XBox controllers here: https://www.ultraengine.com/learn/GamePad?lang=cpp I have not used Steam input myself. I did some work with their early Steam controller API, but I think that got deprecated.

I just updated the editor with the recent fixes.

When I modify the shadow casting setting of a model in the asset window, the view updates instantly in the main window viewports, before I even save the model.

Is there still any problem with this?

I think this is the same thing:

Directional lights will now use the camera for the LOD distance.

Any news?

Any problems still?

It works now. I believe this is fixed. I don't understand what is supposed to happen in the code you posted, so please let me know if anything is not right.

Fixed Camera::SetUniform integer variables. Added Camera::SetUniform Mat3 and Mat4 overloads. Camera::SetUniform texture will work with either a GLSL uvec2 or a uint64.

Wouldn't it have to be cast to a uvec2? The first four bytes could form a zero and the second four bytes could be another value, and an uint would not detect that.

I will do this so it will choose the type based on what is in the shader, and you can use either. It also stores a shared pointer to the texture so it can't get deleted as long as it is bound to the shader: void RenderShader::SetUniform(const int location, std::shared_ptr<RenderTexture> tex) { if (not Finalize()) return; if (location < 0 or location >= uniforms.size()) return; auto& u = uniforms[location]; if (u.defined and u.resource == tex) return; if (u.size != 1) return; GLuint64 handle = 0; switch (u.type) { case GL_UNSIGNED_INT64_ARB: if (tex) handle = tex->GetHandle(); glProgramUniformHandleui64ARB(program, u.location, handle); break; case GL_UNSIGNED_INT_VEC2: if (tex) handle = tex->GetHandle(); glProgramUniform2uiv(program, u.location, 1, (GLuint*)handle); break; default: return; break; } glCheckError(); u.defined = true; u.resource = nullptr; if (handle) u.resource = tex; }

The only downside is you can no longer check if the value is 0 to disable the texture.

Don't use integer uniforms right now.

No, that will go out tomorrow.

https://www.ultraengine.com/learn/Stream_Write?lang=cpp