Jump to content

SpiderPig

Developers
  • Posts

    2,203
  • Joined

  • Last visited

Everything posted by SpiderPig

  1. 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.
  2. 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.
  3. Great job! Looks amazing. I'll try this out in game very soon. Thanks!
  4. Yeah it looks like the lighting routine. Are you seeing the same thing on your machine or is it specific to mine and reepblues?
  5. I get that. Personally I'd be happy to pay for a subscription if it meant getting updates quicker.
  6. 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.
  7. Oh okay, I can. I thought the standalone was always updated first.
  8. I just updated the standalone and the code in the 1st post still doesn't work. It still says "No Font Found"
  9. 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.
  10. 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?
  11. 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?
  12. Is my suggestion somthing you think you can add or are you reluctant to do so for that reason?
  13. Oh okay. That dosn't bother me. I've been able to debug my plugin okay.
  14. I can see the vertex class supports bone weights and such. Even if it didn't, I would still very much like to use the plugin system for this. At the very least for static objects like foliage.
  15. What sort of limitations? Does it handle animations?
  16. I'm pretty sure I need to use the plugin system. I'm getting the material path from within the model file like this inside the plugin: auto str_len = 0; reader.Read(&str_len); auto material_path = reader.ReadString(str_len); What I think will work would be something like this: mesh->SetMaterial(material_path) What I was hoping for was that my game would load the material file so that if I use a file watcher. The material asset could be auto reloaded if I edited that file manually.
  17. 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.
  18. 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.
  19. While on the topic - will it handle zip files bigger than 4GB?
  20. I've tried various things no matter the data for the material, it appears to be ignored when loading the model.
  21. 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
  22. 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?
  23. 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";
×
×
  • Create New...