Hello @vaishhg, Welcome to the Maxon developers forum and its community, it is great to have you with us! Getting Started Before creating your next postings, we would recommend making yourself accustomed with our forum and support procedures. You did not do anything wrong, we point all new users to these rules. Forum Overview: Provides a broad overview of the fundamental structure and rules of this forum, such as the purpose of the different sub-forums or the fact that we will ban users who engage in hate speech or harassment. Support Procedures: Provides a more in detail overview of how we provide technical support for APIs here. This topic will tell you how to ask good questions and limits of our technical support. Forum Features: Provides an overview of the technical features of this forum, such as Markdown markup or file uploads. It is strongly recommended to read the first two topics carefully, especially the section Support Procedures: How to Ask Questions. About your First Question I assume this is about Deadline? I am also not sure that I understand the question correctly. Let me recap, so that we are sure we talk about the same thing. You have a scene Original.c4d and you export it to the Redshift Scene format OriginalProxy.rs. Then you create a Cinema 4D scene Composition.c4d and there create one or multiple Redshift Proxy objects referencing OriginalProxy.rs. Then you export that scene as a Redshift scene as CompositionProxy.rs. You now want to access information about Original.c4d or OriginalProxy.rs when loading CompositionProxy.rs with a RS Proxy object into a Cinema 4D scene (or by extension see that information in the Asset Inspector). That is not possible. rs is the Redshift scene format which works across the full landscape of DCCs supported by Redshift. The Redshift format has no such concept as a generator and just discretizes all smooth/procedural geometry data. When you export a Cinema 4D scene to the Redshift rs format, it will among other things just walk your scene and collect all the geometry caches and save them discretely in the RS format. For Redshift it does not make any difference if it collects the cache of a Cube generator object or the cache of a Redshift Proxy generator object. In the eyes of Redshift these are both just two procedural geometry generators which must be discretized/baked for export (not entirely true, because Redshift Proxy objects are cached in the Redshift Core itself and not in Cinema 4D, but close enough). As soon as you save a scene in the RS format, all information is lost that something once was a generator and the parameters it held. The Redshift Core also does not know a concept such as asset data or the Asset Inspector, as that is a Cinema 4D specific concept. So, such data is not stored in the rs format either. So, to answer your questions: You cannot reach into the past like that. Neither directly via the Asset Inspector and its API, nor indirectly by for example traversing the scene graph of a scene. In fact, RS Proxy objects do not even have caches in the Cinema 4D world, unless you set Preview to Mesh. The actual data resides discretely in the in the Redshift Core. As an example, when we have this scene which holds two proxies and we run this script on it to, print the scene graph string of each object in the scene, we can see both proxies only hold discrete polygonal data: import c4d import mxutils doc: c4d.documents.BaseDocument # The currently active document. def main() -> None: """Called by Cinema 4D when the script is being executed. """ for obj in mxutils.IterateTree(doc.GetFirstObject(), True): print(mxutils.GetSceneGraphString(obj)) if __name__ == '__main__': main() [image: 1768559309357-2c7c3701-ac06-43d6-b038-bea506e05083-image-resized.png] When we now save that scene as an RS scene file and load that in an RS Proxy object in another scene, we will see that it only contains one blob of discrete geometry. [image: 1768559425329-627111d5-a034-409f-a93a-b7e064b9f044-image-resized.png] Cheers, Ferdinand

Thank you @ferdinand for the help! Write raw memory does help a lot, appreciate!

Hello @uogygiuol, Thank you for the added details. Yes, reducing the complexity of questions is the right thing to do, thank you for doing tit. Essays are counterproductive, as we then tend to overlook things (q.e.d., I overlooked the fact that you wanted to mangle the scene file in this thread). In general, trying to mangle a file beforehand is not a good route, as you always risk invalidating the file. For your very specific scenario - very simple scene graph, just geometry, no materials, animations or other dependencies - it could make sense. I briefly talked with the owner of our GLTF-importer, and we do not do any sanity checking, e.g., comparing nodes with meshes. So, you could just 'clean up' the scene graph ("nodes") of the file, and Cinema's GLTF importer will then just ignore extra data in fields such as "meshes". How fruitful this will be, you will have to find out yourself. I already had the hunch that your are here surfing on the edge of what is sensbible, and GLTF JSON files which translate to gigabytes of memory are certainly an edge case, due to the fact that text-based file formats are usually a bad choice for such heavy data. Using Python to Read JSON My guesstimate would be that when you throw a GLTF JSON file at Python's JSON parser - which takes five minutes to load in Cinema 4D - to mangle it, you end up with a net-loss or tie, because you loose most or more than the won time in that Python JSON stage. Python's json module is mostly written in C to make it performant, but that is still a lot of JSON to deserialize, modify, and then serialize. One idea could be to use re, i.e., regular expressions, to find the "nodes" section in that file, just deserialize that from JSON, modify it, serialize back to a JSON string, and write it back in place, and by that sidestep having to deserialize that whole file. The problem with all that is that json.load allows you to pass a file object, allowing you to bypass the Python VM entirely and let the data reside in C until the parsing is done, while re does not allow you to regex a file object directly (AFAIK), you always must read the file object into lines or chunks to then pass these strings to the re module. I.e., you would have to load that whole file into a Python string first. What would come here out on top, I have no clue, but my hunch is that re might loose, as Python's string handling is not the fastest. Alternatives might be 3rd party libs such as isjon (a lazy JSON loader) but I do not know how performant it is. For this section it would make a huge difference if you could predict the position of "nodes" in the file, either exactly as a chunk offset, or in the form of 'I know that it is always very close to the end, so let's regex parse the file in reverse'. Using a Binary File Format But the fact remains that text-format file types, e.g., JSON GLTF, become extemely ineffcient once you pass the ~100 MB barrier. Using something like binary GLTF or another binary format such as FBX will likely speed up your Cinema 4D loading times quite a bit, no extra steps required. And to be clear, text-based file formats are always wildely ineffcient. It is just that below the ~100 MB barrier (adjust for the beefiness of your machine), you can drown that inefficency with pure computing power and have the nice advantage of a human-readble file format. Cheers, Ferdinand