Closed Ace-Dragon closed 4 years ago
I'm not sure if I understand, sorry :( As far as I understand, if you instance the imported scene and add children to it, or make changes to it, those should be kept even in re-import of the original scene
On Mon, Jul 4, 2016 at 5:51 PM, Ace-Dragon notifications@github.com wrote:
A picture says a thousand words [image: godot_proposal1] https://cloud.githubusercontent.com/assets/10081256/16569560/8d8f7794-41fd-11e6-89c3-9ba188c8205f.jpg
Now I'm not asking we need to try to reintroduce the old merge commands in full, but the merging in question which I am proposing would only apply to merging in instances of other scenes already in place. The idea would be that this approach would greatly reduce the complexity in making a functional merge possible because scene instances are entirely self-contained and it would be far easier for Godot to determine how to add them back (unlike the 1.x series where the code may have to figure out complex non-instanced hierarchies added to the scene). In other words, non-instanced nodes added to the scene would still disappear (and as such Godot wouldn't have to deal with them).
I guess it could or could not be explained better (hence why I added the image)
Thoughts?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/godotengine/godot/issues/5553, or mute the thread https://github.com/notifications/unsubscribe/AF-Z2_tWIKUQ5sSPIxcF457I7V6lL1z1ks5qSXJHgaJpZM4JEpT_ .
This isn't related to adding children to an instance of an imported scene, what I'm talking about here is importing a scene from Blender and then adding instances to that exact scene (ie. they are children of the non-instanced content that was imported).
The issue right now is that you can have a nice setup with child instances, but re-importing the scene will erase every node that wasn't a direct result of the original collada information (so instances, raycasts, anything that was added disappears).
The tricky thing though is if I was to have a complex tree with a lot non-instanced content added to the imported scene, hence the idea that we could make things simpler while still avoiding loss of data by just adding back the scene instances to the tree.
Now I did just find that I can do things in reverse and make the Blender scene a child of the setup (rather than visa-versa), but being able to do what I proposed could make things easier and more flexible (especially when it comes to editing established content with hundreds of instances throughout the game).
The problem I found is that it's really difficult to find a right way to merge an old scene with new, there are just too many ways to do it and it seems no one can be happy.
Right now what you can do is inherit the scene you imported, and then do everything you want to it, later instance it. This is probably what will be the "official" way to deal with local changes to the scene.
Still, an alternative I've been thinking about is to allow import scripts to also have a merge() function, where you can decide how to merge old scene with new if you want.
That merge() function you propose, it seems like an interesting way to tackle this issue (especially if there's no case out there where it becomes obvious that 'it should be merged in a specific way').
Perhaps if that was done, there could be a bundle of scripts made available that gives examples of common ways a scene might be merged (especially since there's little documentation as to how to write an import script at the moment).
The problem with inherited scenes is that while you can add children to existing nodes, you can't actually change its structure, so this function is limited. I think the best path one can follow currently is to write import script. This is currently not well documented and is not noob-friendly and noob can easily get into trouble with his assets at start, which might be frustrating. But some tasks can be handled by importer in user friendly way allowing to do most common things using GUI without need for script. These are:
All of this can be implemented as script, but I think some standard things could be either pre-implemented as standard scripts or be made as part of importer. All this importer script writing is still a mystery, so expecting beginners to handle these is really naiive.
On Tue, Jul 5, 2016 at 1:36 AM, Juan Linietsky notifications@github.com wrote:
The problem I found is that it's really difficult to find a right way to merge an old scene with new, there are just too many ways to do it and it seems no one can be happy.
Right now what you can do is inherit the scene you imported, and then do everything you want to it, later instance it. This is probably what will be the "official" way to deal with local changes to the scene.
Still, an alternative I've been thinking about is to allow import scripts to also have a merge() function, where you can decide how to merge old scene with new if you want.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/godotengine/godot/issues/5553#issuecomment-230360621, or mute the thread https://github.com/notifications/unsubscribe/AAAX0_Upp95PF02Cu1GJN51bUob-P9tqks5qSYrmgaJpZM4JEpT_ .
On Tue, Jul 5, 2016 at 2:31 AM, Ace-Dragon notifications@github.com wrote:
That merge() function you propose, it seems like an interesting way to tackle this issue (especially if there's no case out there where it becomes obvious that 'it should be merged in a specific way').
Perhaps if that was done, there could be a bundle of scripts made available that gives examples of common ways a scene might be merged (especially since there's little documentation as to how to write an import script at the moment).
It looks like you and @reduz speak in entirely different languages, and sorry, I can't help with understanding/ Probably you better explain what you really want as it looks like you're from some different world now. Sorry.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/godotengine/godot/issues/5553#issuecomment-230363553, or mute the thread https://github.com/notifications/unsubscribe/AAAX0-Xm0QT5ff4HADAJVfmZvOnLl8O0ks5qSZfkgaJpZM4JEpT_ .
One thing I always have to do on reimport of my 3D character scene is to re-add my animation tree controller. It would probably quite simple to do this with an import script I'm guessing, but I haven't tried yet.
I ran into this issue recently. I imported a dae of a building then proceeded to add a mesh to it in Godot. Every time I edited the dae, I had to readd the mesh.
If merging on autoload is not very likely, maybe some sort of an easy "switch off" for reimport or a "do you want to make a copy before reimport?" question?
Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine.
The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker.
If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance!
A picture says a thousand words
Now I'm not asking we need to try to reintroduce the old merge commands in full, but the merging in question which I am proposing would only apply to merging in instances of other scenes already in place. The idea would be that this approach would greatly reduce the complexity in making a functional merge possible because scene instances are entirely self-contained and it would be far easier for Godot to determine how to add them back (unlike the 1.x series where the code may have to figure out complex non-instanced hierarchies added to the scene). In other words, non-instanced nodes added to the scene would still disappear (and as such Godot wouldn't have to deal with them).
I guess it could or could not be explained better (hence why I added the image)
Thoughts?