Consistency when reimporting meshes

[christian.wolf2]

Hi,

I have a short question regarding mesh-consistency when we reimport them via code. We currently evaluate the idea of reworking our custom importer-pipeline based on the Cad/Fbx-Importer. Mainly we have a simpler version of the UNIGINE Editor importer, where the user sets various parameters. When importing for the first time, we create a new importer for it, set the parameters and do the import. Simply as that and no issues at all. The user than uses the meshes for further tasks, link them with custom scripts, e.g.

For an future release we want to support an kind of "re-import" of the previous generated file. Maybe the user adds a couple of surfaces in an external CAD-program, rename them or even remove them. So mainly the following questions arised during our discussion, what aren`t described in the documentation:

• If the exact file is re-imported, does the internals replace the previous nodes with the current one? Like are Guids the same, the already in-used smart pointers in our scripts, e.g.?
• If some surfaces are removed, how does the already existing nodes in the our internal system behaves? Does the meshes become invalid (so no surface is drawn) or will the node instances also become invalid?
• Do we need to handle something special in the post-processing event, like re-linking materials,...

 

Thanks in advance

christian

[silent]

Hi Christian,

1. If there will be no guids changes everything should be fine. Maybe you would need to manually call Render::reloadResource() to update the actual geometry from file.
2. There might be issues with material assignments, but that would be better to test on your side to understand the pipeline better and to understand if it fits your needs.
3. Yep, the material assignment may be the only thing you need to do if something went wrong.

Thanks!

[christian.wolf2]

Hi silent,

thanks for the quick reply.

3 hours ago, silent said:

If there will be no guids changes everything should be fine

And that is the tricky part for me in my understanding. :) How does the guids be created during the standard CAD/FBX-import? I guess UNIGINE will be generating on based on some parameters. I just want to understand which parameters I need to take care of that influences the GUID.

Also, when doing an Re-Import, is overriding the previous files okay (so do the engine take care about runtime changes of the source meshes) or do I need create a direct copy beside the original one and do some "swapping" between the old and the new files?

Best

Christian

[silent]

Engine is trying to keep guids of the files that were already created before. I think you can experiment with couple of different test files to understand what you may expect here.

 

Quote

do I need create a direct copy beside the original one and do some "swapping" between the old and the new files?

Probably, calling Render::reloadResources() would be enough. It's hard to suggest anything here without seeing the actual content and how it supposed to be be imported or re-imported :)

[christian.wolf2]

Thanks silent for the reply. We are still working on an 2.15.1 engine codebase (with minor chance to upgrade it at the moment), so Render::reloadResources doesn`t seem to be available for us. Are there any workaround or this?

Regarding our usecase, I attached an screenshot from our current implementation:

Spoiler

It is basically an more lightweight version of the UNIGINE importer for our software. The user (mainly engineers and technicians without any deep 3D background) should be able to import CAD-files and other 3D models into our software and keep working with it any further. Changes in hierarchy is expected, but for now no deletion of any objects. If there are any new CAD/3D-models available, our users should be able to do an simple re-import to keep the 3D-asset up-to-date with their technical planning. However, all further customizations in our editor should be not affected from that.

Hope this makes everything a little bit clearer for you. :)

Best

Christian

[silent]

Yeah, thanks for the additional information. Pictured something very similar :)

But I would recommend to evaluate how hard it would be to add reimport functionality into the already existing codebase, rather than rewriting it all to the built-in import system. Maybe it would be easier to achieve :)

As far as I remember, in 2.15.1 you can tell the engine that file was changed on fly using different method: FileSystem::changeVirtualFile(). Maybe that will help.

Thanks!