Huge File Sizes

[EitanElbaz]

Hello once again

GILES has been awesome to work with so far.

I have however been noticing that the sheer amount of data being generated when saving a level is absolutely enormous.

A level with 10 or so objects will often exceed 10MB of pure JSON data.

Parsing a large amount of JSON and instantiating all of the objects at once also causes quite a lag spike as you might imagine :P

[EitanElbaz]

Update:

It seems that one of my objects (a very simple cannon) causes GILES to generate around 13MB of JSON o.O

The object was created using ProBuilder and was colored in with ProBuilder's Vertex Color brush.

The JSON contains a huge array of of all of the vertices, normals and probably(?) all of the colouring information.

[EitanElbaz]

Some of my gameobjects with particle systems attached to them generate around 400KB of JSON.

It feels like GILES should optionally only store a reference to the prefab since I suspect that most games will actually disable the "Show full inspector" button anyway.

A lot of space would be saved if GILES only generated JSON for Transform settings and any settings for custom scripts on the object.

[EitanElbaz]

Another update:

(This is specifically related to using ProBuilder objects in the scene)

on pb_SceneNode.cs

We've got the following line (line 80 or so):

if( c == null || c is Transform || c.GetType().GetCustomAttributes(true).Any(x => x is pb_JsonIgnoreAttribute)) continue;

Making it also ignore pb_Object Massively decreases the size of the output file.

pb_Config.cs currently has has hash set defined with a bunch of Unity types the inspector ignores by default.

public static readonly HashSet<Type> IgnoredComponentsInInspector = new HashSet<Type>()

It would be great if a similar (configurable) list of types could be adjusted by developers and applied when serializable objects are created in pb_SceneNode.

I'll branch off and create a quick implementation for this which may need some improving.

[karl-]

It feels like GILES should optionally only store a reference to the prefab since I suspect that most games will actually disable the "Show full inspector" button anyway.
A lot of space would be saved if GILES only generated JSON for Transform settings and any settings for custom scripts on the object.

That's what it should be doing. It's been a while, but I think the reason it's writing all that mesh data comes down to a bug in how pb_Object prefabs are instantiated. Namely it's creating a mesh instance instead of pointing to the prefab asset. GILES is incorrectly thinking that the mesh data has been modified (which is planned to be supported) and writing the entire mesh to JSON. I think fixing that behavior would preferable over just ignoring pb_Object entirely.

[EitanElbaz]

That's what it should be doing. It's been a while, but I think the reason it's writing all that mesh data comes down to a bug in how pb_Object prefabs are instantiated. Namely it's creating a mesh instance instead of pointing to the prefab asset. GILES is incorrectly thinking that the mesh data has been modified (which is planned to be supported) and writing the entire mesh to JSON. I think fixing that behavior would preferable over just ignoring pb_Object entirely.

It does store a reference to the prefab. I didn't fully read the code at the time of writing that.

That's a valid point about pb_Object, but I still feel like there should be a way of ignoring types of components. There may be a scenario where a third party asset causes GILES to do something similar to what pb_Object is currently causing it to do.

Developers may also be using third party components, but don't want to add a JSON ignore attribute because the next update to that asset will get rid of it. Subclassing a component just for the sake of adding the JSON ignore attribute will also create a lot of clutter.

---

Somewhat offtopic, but do you know when you plan on opening up the beta access to more people? I'd like to pay some sort of early access fee to support the cause.

[karl-]

Developers may also be using third party components, but don't want to add a JSON ignore attribute because the next update to that asset will get rid of it. Subclassing a component just for the sake of adding the JSON ignore attribute will also create a lot of clutter.

A good point. I've added static methods to register custom types in pb_Inspector (AddIgnoredType and RemovedIgnoredType). You could use a single static config class marked with InitializeOnLoad to bulk manage these registrations.

Regarding the pb_Object storing all it's mesh data, I've been unable to reproduce that behavior. Are you seeing that happen for all ProBuilder meshes or just a few?

[karl-]

Somewhat offtopic, but do you know when you plan on opening up the beta access to more people? I'd like to pay some sort of early access fee to support the cause.

I've been busy with the ProBuilder 2.5 update and Polybrush lately; haven't had a chance to work on GILES. I think the general idea is to open it sooner than later though. I'll speak with Gabriel next week on how to proceed with opening up access.

[EitanElbaz]

A good point. I've added static methods to register custom types in pb_Inspector(AddIgnoredTypeand RemovedIgnoredType). You could use a single static config class marked with InitializeOnLoadto bulk manage these registrations.

That's great, thanks!

Regarding the pb_Objectstoring all it's mesh data, I've been unable to reproduce that behavior. Are you seeing that happen for all ProBuilder meshes or just a few?

I created a simple cylinder and used the Vertex Color brush.

-- Parent Gameobject (various custom scripts and a box collider)
---- Child Cylinder Gameobject (this is the ProBuilder object. pb_mesh, pb_Entity, pb_object, )

Note that I also haven't upgraded to ProBuilder 2.5 yet. I'm on 2.4.11f0 revision 4081 to be precise.