The thing is that, .p2 can be used for rendering (or transport), or for generating .pds file and edit in the editor. For rendering, we only need to keep the rendered scene the same, and can even optimize the format a bit (e.g., shorter names, better separation of files to enhance parallelism). For editing, we may want to keep at least some information such as packet names and comments. So this pretty much comes down to the following conclusion:
For rendering, do not need to keep things that will not change the output of the renderer. We can even optimize it quite a bit.
For editing, the more we can keep the better. One way to do this is to store extra information extracted from .p2 and store it as meta info for .pds.
Whether to keep other things (such as executors) can follow this thought process.
Problems
However, named packets can be expanded multiple times, is it even possible to restore their original structure? Kind of like trying to work out the original macro call sequence from expanded result. Also, data read in may already be modified, trying to store them as they were loaded does not make sense (e.g., two resource uses the same named data packet, but both struct objects are modified differently, no longer can share a named packet).
Current Implementation
Named packets are treated as macros for writing scene file--they are parsed, expanded, and discarded once the scene loading process is done. When named packets have name collision, the newer one will overwrite the old one and emit an overwriting warning. One exception is that name with a '$' prefix means it is "cached" and can be overwritten without warning.
In the future we may allow named packet "resources", with '@' prefix to signify that they are tracked and saved. We will see if these updates are required.
Background
The thing is that, .p2 can be used for rendering (or transport), or for generating .pds file and edit in the editor. For rendering, we only need to keep the rendered scene the same, and can even optimize the format a bit (e.g., shorter names, better separation of files to enhance parallelism). For editing, we may want to keep at least some information such as packet names and comments. So this pretty much comes down to the following conclusion:
Problems
However, named packets can be expanded multiple times, is it even possible to restore their original structure? Kind of like trying to work out the original macro call sequence from expanded result. Also, data read in may already be modified, trying to store them as they were loaded does not make sense (e.g., two resource uses the same named data packet, but both struct objects are modified differently, no longer can share a named packet).
Current Implementation
Named packets are treated as macros for writing scene file--they are parsed, expanded, and discarded once the scene loading process is done. When named packets have name collision, the newer one will overwrite the old one and emit an overwriting warning. One exception is that name with a '$' prefix means it is "cached" and can be overwritten without warning.
In the future we may allow named packet "resources", with '@' prefix to signify that they are tracked and saved. We will see if these updates are required.