SpiderPig

Would it be possible to get the previous frame in the fragment shader? I don't mind it being 1 or 2 frames out of sync, would that solve the reading & writing at the same time issue you mentioned?

Regarding the conversation of ASIMP and GLTF in the workshop today - I think all problems are solved by creating a unique format for Ultra. My exporter for blender (although only for static models - for now ), with a few clicks I have everything exported that works straight away. I can't speak for other peoples workflow, but this is mine in a nutshell. Buy / Make assets Store them in a library folder so that they can be used in any project (also serves as a backup) Load them in blender and save the blend file in the same library folder Fine tune the mesh and materials. Make a mesh collider if needed (some already have one) My Format: Export to Ultra - done! GLTF Export LOD0 Export LOD1 Export LOD2 Export LOD3 Export Collider Mesh Load the editor Open each material Convert textures Open the model and load the collider from the mesh Delete the GLTF for this collider If I need to edit the model or material further. Open blender Edit things My Format Export to Ultra GLTF All of the above again! If I edit the material in the editor, then my source in blender is no longer the same. 99% of the time any change I want to make will apply to all projects, so I want it changed in the source file (.blend) not in the lone project. If GLTF or any other format doesn't improve on the current workflow. There's no way I'm staying with GLTF.

I see what you mean. It would be no "easy" task for the user, but for those of use who know how all the positioning would be done in a shader function. The idea of a MeshLayer class would be to construct a grid of meshes from a single object. Then in our shader function we could write some code that could sample a texture to offset the mesh in that cell, to get some randomness (and even height). The only thing it would be suited for is large quantity of objects that follow a sort of grid like pattern. (3D grid would be even better). Like foliage; city blocks and maybe even large swarms of enemies or insects that could be swapped in for an actual model the closer the player got to them - like a boid system. I'm sure there are more uses. I will write something like this myself if not. I'm not as smart as you so it would take me more than 3 days.

I'm watching the video of todays workshop. Your mesh layers does exactly what I need 😁 and I agree with the others about how it should be a seperate class from the terrain. Somthing we can use idenpenantly would be very powerfull. Firstly I could use it for my voxel terrain foliage system - which is the exact same as yours but can work in caves and such too. Also it could be used for making cities with huge amounts of buildings and I'm sure many other things too. 🙂 What do you think about this?

Yeah it's a sphere. I'm only setting the SPEC and DIFFUSE environments maps for now so it helps with the PBR lighting, not sure how the skydome is effecting that, I'll investigate!

It would kind of be a post effect, yeah. Okay, so the colour texture is first written to by the 3D camera, then added too with the UI camera. At the very least I might be able to capture a screen shot and use that as the texture. Wouldn't be real-time but it might look good.

Can I get the colour buffer in the fragment shader of a single camera? 🤔

I like the transparent window effect in the editor - could this be done with a shader? I'd like to get a similar effect on a sprite in my UI for the inventory panels. Is it pretty much just a blur effect?

I just tried this in game and it looks awesome, albeit a bit bright at the moment (might be my settings, not sure).\ Also it didn't work with the environment maps set. Should it work with this you think? auto specmap = LoadTexture("Materials/Environment/Default/specular.dds"); auto diffmap = LoadTexture("Materials/Environment/Default/diffuse.dds"); world->SetEnvironmentMap(specmap, ENVIRONMENTMAP_SPECULAR); world->SetEnvironmentMap(diffmap, ENVIRONMENTMAP_DIFFUSE);

I've just update and copied the shaders folder only into my project. I saw this in the console output; Failed to link shader: C:/Users/Matt/Documents/Ultra Engine/Projects/TheSeventhWorld_DevGrounds/Shaders/Shadow/Shadow_Animated.vert C:/Users/Matt/Documents/Ultra Engine/Projects/TheSeventhWorld_DevGrounds/Shaders/Shadow/Shadow.frag Link info --------- error: "materialID" not declared as an output from the previous stage

Oh, thanks. 😁 I had this feeling it wasn't a bug and I was just going to have to up double the textue size to try and fake it.

I'm rendering a camera to a texture and tried setting MSAA to 2 (and above) and got a black texture as a result. Should this work or is it a bug? If it's a bug I'll put an example together.

Being an animated model I can't set AlphaMask in the editor and re-save it, so I added the line "alphaMode":"MASK" in the GLTF to the appropriate materials. Loading the model back in the editor, it does what it should (transparent hair and eyelashes) but you can see in the thumbnail that the character is missing it's head and hands. I get the same thing in my game. I will PM you the model.

This is working now.

Great job! Looks amazing. I'll try this out in game very soon. Thanks!

Yeah it looks like the lighting routine. Are you seeing the same thing on your machine or is it specific to mine and reepblues?

I get that. Personally I'd be happy to pay for a subscription if it meant getting updates quicker.

Okay. You might need Elon's StarLink

I've been meaning to ask. Is there a benefit to paying for a subscription over buying outright on Steam? I always thought the standalone was updated before steam. Or, are you planning on adding some sort of benefit after v1.0.0 is released? Like subscribers get weekly updates on the dev branch over monthly / yearly updates on Steam? Just curious.

Oh okay, I can. I thought the standalone was always updated first.

I just updated the standalone and the code in the 1st post still doesn't work. It still says "No Font Found"

Hmmm, I don't think you should get rid of the plugin system. It'd be like getting rid of the editor extension system. There are very good reasons to have both of them. Being that you are a one-man developer, we have to wait considerable amounts of time for you to be able to implement features. With plugins and extensions we don't have to wait. We can do these things ourselves. You said yourself Ultra is targeted for the more advanced users. Plugins are advanced and should remain for that purpose. I could wait for you to fix GLTF up a bit so it's workflow is improved. But how long should I wait? Should I release a commercial product only to have plugins removed half way through its development? If you do that, I think your only making yourself the bottleneck again because we would then have to beg and wait for things to be implemented. You'd only be making more work for yourself. How Ultra works at the moment feels really smooth to me and starting to remove things likes this concerns me that there might be something else my game relies on that might be removed in the future. I really don't want to be in a position where this might happen. This is what Leadwerks was like. This is honestly why I put so much time and effort into doing things myself; voxel terrain, foliage system, physics system, character system, and now model system, etc. Because that way, I know they work, I have the source code and I can fix bugs / add features whenever I want. I've given it some more thought. I don't think adding what I suggested is catering only for me. I also don't understand how it's a "major" part. It seems pretty simple to me, but then again I haven't seen your code for LoadModel(). I mean, clearly LoadModel is already searching a plugin and creating a material for each mesh, so, is the following code really that difficult? shared_ptr<Model> Ultra::LoadModel(shared_ptr<World> world, WString filepath) { ... auto mat = LoadMaterial(data->material_path) if(mat != nullptr){ mesh->SetMaterial(mat) } The plugin SDK clearly supports the loading of custom / other known, model formats. It clearly has an option to assign a material to mesh which isn't a custom feature. I think that should be a material filepath as well as being able to construct the material dynamically. Like I said, it's not a custom feature. I simply want to assign a material to a mesh within the plugin SDK and have Ultra::LoadModel() load that material and apply it. The only reason I'm insisting on all this is because of the fact a material can be assigned to a mesh in the plugin SDK. If your saying - that LoadModel() should not be loading and applying materials then I will have to find another way to do what I want. But from what I've seen, LoadModel() does just that. It loads models and applies the specified material. EDIT : At the end of the day, if I truly can't convince you of this. I will have to do away with LoadModel() and write my own importer to replace it.

Then I suggest the GLTF experience is drastically revamped. It's okay for people who want to tinker, but for people like me who actually want to develop a commercial product. It's a pathetically mind numbing experience that's taking huge amounts of time. Hence why I'm forced to make my own plugin. There's also this which is what the topic was about. Now this IS already in the plugin SDK. What about the fact that this doesn't work? auto mtl = new GMFMaterial(file); mtl->text = "{\"material\":{" "\"color\": [1,0,0,1]" "}}"; mtl->path = L"material0.mat"; mtl->data = (void*)mtl->text.c_str(); mtl->datasize = mtl->text.size(); mesh->SetMaterial(mtl); The model is loaded in Ultra and the mesh has a material but "mtl->text" doesn't change anything. Is this not its intended use?

I'll see if I can explain it better. This is the code in the plugin the saves a materials information. "path" will be set to "Materials\\MyMaterial.mat" bool GMFMaterial::Save(MemWriter* writer, const int flags) { uint64_t start = writer->Pos(); writer->Seek(start + sizeof(uint64_t)); writer->Write(path); writer->Write(&datasize); if (data != NULL) { writer->Write(data, datasize); } uint64_t end = writer->Pos(); uint64_t sz = end - start; writer->Seek(start); writer->Write(&sz); writer->Seek(end); return true; } In the engine: LoadModel("MyModel.myformat") should not only load the model, but look at that material path that was written to the stream for the mesh (writer->Write(path);) and then load that material and apply it to that mesh. Does that make sense?