christian.wolf2 Posted January 11, 2022 Share Posted January 11, 2022 (edited) Hi all, I am trying to save a world with runtime generated assets inside. Currently, I am importing .fbx-files via the importer during runtime. All necessary files (.node/.mesh/.mat) were generated without any issue and I can interact with it as usual. But when calling World::Save() the engine won't save the complete world with my imported files. In the past, the node ownership was handled manually and passing new nodes to the editor does the trick. But it was removed with the 2.10 update and your re-work of node handling in general. So is there an way to add an runtime generated node to the engine, so it will be also saved in the .world-file? Best Christian Edited January 11, 2022 by christian.wolf2 Link to comment
devrom Posted January 11, 2022 Share Posted January 11, 2022 Hi Christian, did you try setSaveToWorldEnabled? Best regards 1 Link to comment
christian.wolf2 Posted January 11, 2022 Author Share Posted January 11, 2022 Yes, enabled it right after import stage for the root-dummy, also with SetSaveToWorldEnabledRecursive(true) but still no difference in my .world-file. Link to comment
silent Posted January 11, 2022 Share Posted January 11, 2022 christian.wolf2 Everything should work fine with SetSaveToWorldEnabled call (at least we are using the same API inside Editor): node->setShowInEditorEnabledRecursive(true); node->setLifetime(Node::LIFETIME_WORLD); node->setSaveToWorldEnabledRecursive(true); Could you please prepare a small reproduction scene so we can check with debugger on our side as well? Thanks! How to submit a good bug report --- FTP server for test scenes and user uploads: ftp://files.unigine.com user: upload password: 6xYkd6vLYWjpW6SN Link to comment
christian.wolf2 Posted January 11, 2022 Author Share Posted January 11, 2022 Hi silent, I figured out, what the problem was. I called detachReference() from the imported file before SetSaveToWorldEnabledRecursive(true). This seems to have no effect. Is this an expected behavior? Calling this function before detaching from the reference gives me the correct result. Old code: NodeReference importedNodeReference = dataImporter.ImportedNode; //returns the loaded NodeReference from our .fbx file Node detachedNode = importedNodeReference.DetachReference(); //detach our node from the reference detachedNode.SetSaveToWorldEnabledRecursive(true); //have no effect. New One: NodeReference importedNodeReference = dataImporter.ImportedNode; //returns the loaded NodeReference from our .fbx-file importedNodeReference.SetSaveToWorldEnabledRecursive(true); //this is working - enables saving the node Node detachedNode = importedNodeReference.DetachReference(); //detach our node from the reference //.... Do whatever you want So thanks to both of you and sorry for the confusion. Best Christian Link to comment
silent Posted January 11, 2022 Share Posted January 11, 2022 Looks strange, indeed. Is that from 2.15? We need more time to do a reproduction on our side and see what's going on. How to submit a good bug report --- FTP server for test scenes and user uploads: ftp://files.unigine.com user: upload password: 6xYkd6vLYWjpW6SN Link to comment
christian.wolf2 Posted January 11, 2022 Author Share Posted January 11, 2022 No, we are currently working on 2.14.1.1. It is not an critical action because we found a "workaround" if it is a not an intended behavior. It is only good to know how internals work for future projects and issues like that. Link to comment
silent Posted January 12, 2022 Share Posted January 12, 2022 We've tried to reproduce in 2.14.1.1 and your first code is working fine. So it's not completely clear what happens on your side. Probably the issue itself not in that particular part. How to submit a good bug report --- FTP server for test scenes and user uploads: ftp://files.unigine.com user: upload password: 6xYkd6vLYWjpW6SN Link to comment
christian.wolf2 Posted January 13, 2022 Author Share Posted January 13, 2022 (edited) Hi silent, in order to reproduce the problem, I experimented a bit with NodeReferences. I tried to import an existing .node file via this piece of code from the documentation: https://developer.unigine.com/en/docs/2.15/api/library/nodes/class.nodereference?rlang=cs#detachReference_Node As far as I understand, I can detach a node from a reference to use it on its own. But when I tried the example code in a project (the template C# project from SDK browser reproduces the same) and I executed the following code: NodeReference referenceNode = new NodeReference("csharp_template/template_props/primitives/sphere.node"); Node sampleNode = referenceNode.DetachReference(); referenceNode.DeleteForce(); sampleNode.Enabled = true; The application crashes right after deleting the NodeReference using DeleteForce(), leading the sampleNode as a null-pointer (seems to be deleted as well internally). Is this an intended behavior (because from the Documentation I read otherwise)? EDIT: I can finally reproduce the issue. The error appears, when a .node is created at runtime and loaded from a NodeReference right afterwards. When the NodeReference already exists (it was created in the editor for example), than everything is working fine. The error raises in 2.14.1.1 and in 2.15 as well. For further testing, create a new C# project and add the following code to the WorldLogic.h: public override bool Init() { // Write here code to be called on world initialization: initialize resources for your world scene during the world start. Node primitiveNode = Primitives.CreateBox(vec3.ONE); //create a runtime node World.SaveNode("csharp_template/template_props/primitives/example.node",primitiveNode); //save it to as .node NodeReference referenceNode = new NodeReference("csharp_template/template_props/primitives/example.node"); //load it right afterwards sampleNode = referenceNode.DetachReference(); referenceNode.DeleteForce(); sampleNode.Enabled = true; //exception raised return true; } Maybe because of that, the initial issue also exists. Best Christian Edited January 13, 2022 by christian.wolf2 Link to comment
silent Posted January 14, 2022 Share Posted January 14, 2022 christian.wolf2 Thanks, now it's more clear. By default in C# runtime all nodereferences are being unpacked on startup: https://developer.unigine.com/en/docs/2.15/api/library/engine/class.world?rlang=cs#UnpackNodeReferences So you can do a World.UnpackNodeReferences = false; inside AppSystemLogic and everything should work fine. Or if you need to keep UnpackNodeReferences = true you can do detach in the following way: NodePtr sampleNode = referenceNode->detachReference(); sampleNode->setParent(nullptr); Thanks! 1 How to submit a good bug report --- FTP server for test scenes and user uploads: ftp://files.unigine.com user: upload password: 6xYkd6vLYWjpW6SN Link to comment
christian.wolf2 Posted January 14, 2022 Author Share Posted January 14, 2022 34 minutes ago, silent said: So you can do a World.UnpackNodeReferences = false; inside AppSystemLogic and your code will work as expected. Awesome, that solved my problem. Thanks for the explanation. Best Christian Link to comment
Recommended Posts