SpiderPig

Oh okay. I'm going to write a blog about it once I finish the plugin. But I'll explain here too. While GLTF makes a lot a sense there are a few things about it I don't like and I find in-efficient (I know some things I've raised already will be fixed) I don't like folder clutter and GLTF has two files per object (GLTF + BIN) I know about GLB, I've not tested it in while and didn't try as I decided to go with a plugin approach. I also don't like the fact every time I save the GLTF it generates the PNG / JPG texture files, again purely the preference of not having unnecessary files in my workspace. I know they can be removed from the final export. GLTF doesn't store LOD's. This adds more files to manage. You also have to convert textures to DDS. Currently each GLTF file has it's own material which is painful to manage during development. (I know this will change) I have 12 pine tree variations, each with 4 LODS. So that's 48 GLTF files that need changing if I want to adjust the diffuse or specular color, or any material setting. I'm going to write a vertex sway for my foliage, I don't want to go through 100's of GLTF files to change the shader family of all my foliage. The export process from blender requires me to select and export each model / LOD at a time. I'm going to want to adjust geometry in the future, I don't want to export each LOD stage of each piece of foliage over and over. I can export a PHYSICS mesh as GLTF and have the assets editor convert it to a collider. But then I have to delete that GLTF / BIN file because it is no longer needed. This is why I made the plugin for blender so this process now is as simple as selecting the physics mesh in blender and exporting it directly as a collider to the require folder. Ultra will load it automatically it the model of the same name so that is awesome! My Format: Exports one model file containing every LOD needed. Exports each material as a separate JSON file, and (will soon) export / covert textures as DDS. I only need to select the high resolution model in blender and nothing else. Any model of the same name appended with _LOD# will be gathered and exported at the correct LOD stage. E.g. Selected model is PineTree_001 and the following objects are auto exported PineTree_001_LOD1 PineTree_001_LOD2 PineTree_001_LOD3 Auto exports the collider mesh if an object exists of the same name appended with _PHY E.g. PineTree_001_PHY The exported material files can be shared across all 48 models. (provided I can set a meshes material in the plugin SDK with a file path) This drastically improves my workflow. In fact, my game might not even need the editor as if I need to make a material change I'd do it blender so that my source files are all ready to be exported again. I'm going to write another blender plugin that will (hopefully) export any material directly to an Ultra material without the need to export a model with it. This way I can update a single material if needed. The last thing I want to do is edit the material with Ultra and then re-export from blender one day and have it overwrite that material. It's just better to manage it directly from blender I feel. This way I know that my blender source matches what I have in game. I dare say that most people are going to drag most of their models through an external editing software at some point (probably most with blender), and most models are going to need LODS. Managing this with GLTF is just a bit tedious. I understand why GLTF is good, and if you only want one model from online and never want LODS for it or want to change it's geometry / animation in some way then it will be fine, the process is quick, simple and easy. But as soon as you want to edit it, make LODS and mange everything efficiently I think GLTF falls apart. Getting a GLTF file back into an external software sounds all well and good, but if your manage your project in a sensible and efficient manner (make backups etc.), is it really necessary that you can get it back in? I'd much rather a format that I can export directly to Ultra and have every aspect of it work; LODS, materials, colliders. I need to be able to modify the whole thing with minimal work because I will have 100's of different assets. Rant over.

I'm copying the quake plugin example but maybe I wrong in how I think it works. I've exported an Ultra material file from blender along side my exported model format. I want the correct material files applied to the mesh on that model upon loading in game.

While on the topic - will it handle zip files bigger than 4GB?

I've tried various things no matter the data for the material, it appears to be ignored when loading the model.

Here's a little addon for Blender 4.0 that will export any selected object as a MESH collider for use in Ultra. It may work with other versions of blender but I've not tested it. There are no options for the export process. By default Z is up in Blender so upon export the vertex y and z positions are swapped so that Y is up in Ultra. I could probably add an option to toggle this if it's needed. Any suggestions for improvements are welcome! To Install: Add the folder io_mesh_collider to Blender 4's addon folder. (Blender/4.0/scripts/addons) Launch Blender and navigate to Edit->Preferences Click the add-ons tab look for Import-Export: Ultra Engine Collider and enable it io_mesh_collider.zip

for (const auto& face : meshfaces) { binstream->WriteInt(face.size()); for (const auto& pos : face) { binstream->WriteFloat(pos.x); binstream->WriteFloat(pos.y); binstream->WriteFloat(pos.z); } } Is 'face : meshfaces' each polygon? What is face.size()? How many vertices per face?

My plugin loads geometry fine but it doesn't seem to use the data I assign to the material. Like the Quake Plugin example, I set a similar material to each mesh in the plugin code; 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); When I load the model, m_material for all the meshes are no longer 'empty' but the color is not red. It is still the default white. Are there any extra steps I should take to make it work? OR... Can I do something like this instead of creating a material in the plugin? And have the engines LoadModel() function automatically load the file and use that? mesh->SetMaterialPath("MyMaterialFile.mat") I saw a variable in the mesh class for the material path. Perhaps this should work? mesh->materialfile = L"MyMaterial.mat";

That's a good idea. I'll do that.

Thankyou. This will speed up development for me by exporting straight from blender. 🙂

@Josh I'm writing a blender exporter for my own model format and I want it to also export a mesh as a collider but I don't know the formatting of the .collider file. Is this something you could share?

Are you using 0.9.5? Only the terrain uses spv files in 0.9.5. There is a SpecularGloss_Masked.frag in Shaders/PBR. I'd say Josh just needs to fix the paths in SpecularGloss_Masked.fam to get it too work but you could do it manually in the meantime to see if it works.

I think we needs some options for each of the colliders in the model editor. For example; Box width height depth offset (vec3 offset from position of model) The rest are pretty self explanatory.

Open up any model in the model editor. Navigate to the Model tab and select the model in the tree view. Change the collider to anything other than NONE. Now change the collider back to NONE. Close the model editor and click save. The model editor will not close and the top menu bar has disappeared.

I was thinking it might also be useful to retrieve a list of hooks that have been added. Like, vector<void*> hooks = world->GetHooks(HOOK_WORLD_UPDATE); I would use this mainly for debugging purposes, to make sure that I haven't accidentally added to many hooks or that I am actually removing a hook when I think I am. I would place the hook.size() into my stats overlay so I can see what's going on.

It's not really the shadows either, it's the lighting itself I think.

I'm not sure on the exact setting, but it's a fresh project loading the default start map.

It seems if you divide the line number by 2 it takes you to the error. E.g. line 41315 / 2 = 20657.5. The error is at line 20658.

I found the error in my code. But yeah, the line numbers aren't accurate for some reason.

Hmm, my frag file has only 20k lines. I'd like to know why it says there's an error at line 41,315. My node editor has already solved all the #include directives too, that's why my frag file is so large. There's no #include's left.

What do these numbers mean at the start of the error? Is the one in brackets supposed to be the line number? I miss SPV

Can't get this to work. Am I doing something wrong or is it a bug? I'm sure it worked like this in the past. The font can't be found in the package. #include "Engine.h" using namespace UltraEngine; int main(int argc, const char* argv[]) { auto package = LoadPackage("Data.zip"); if (package == nullptr) { Notify("No Package Found"); } auto font = LoadFont("Fonts\\ZippedArial.ttf"); Notify("No Font Found"); return 0; } Data.zip

@Andy90 and I discussed this on discord. I think we found that exporting from blender as FBX and then letting Ultra's FBX to GLTF take over worked well. At least for now anyway. I think the problem lies in blenders GLTF exporter.

I've noticed a lot of thin banding in the shadows in 0.9.5. I think it's been raised already but I didn't see an official report. This is in the default startup map.

Yeah the UI needs attention. I just threw it together so that I could use it. There are many bugs, I'm actually working on this right now. I did think people wouldn't like entering their steam info. It doesn't have to be used, but I do use it. At the very least I could still manage the steam sdk and just have the user input their steam details into the command prompt that show up, as they'll have to do that anyway to upload. I forgot to remove a couple of options; Everything - should package the entire game folder into one zip file and move it to the export path. All folders - should package all the folders within the game folder into one zip named "data.zip". E.g. The publish folder should contain Data.zip and MyGame.exe as well as any DLL that is needed. All Files - doesn't work atm Separate Folders - Keeps all the folder hierarchy within the game folder but will package all files within that folder. (If this isn't working it's a bug, it works for me) Steam may have changed now... but when I made this it was needed for making small downloads for any updates. I found that if I had one large package (1GB or so) even if I changed one file, steam saw that the whole package had changed so it uploaded the whole thing again and said there was a 1GB update for users. Compressing each folders contents separately helped reduce that update size. Separate Files - doesn't work atm. I was thinking here it could compress / encrypt each file separately. It's using C#. I probably will remake it with Ultra engine for those reasons. Thanks for your input!