JSON and using it as a way to load, save and transmit grouped content


#1

@Piper.Peppercorn
You mentioned last meeting about your thought on using the JSON format as a method of saving / loading object groups locally. While it is currently possible to do the reading remotely and have a script that builds a group of entities, we cannot yet save the json information into a file that could be loaded up (without manually just copying the text and saving it into a file in desktop).

Could you expand on your idea here?


#2

If local object loading is permitted, is it assumed no other clients will see the upload model/script/etc.?


#3

Its more of saving a state and the references to the models.
Like a group of objects in a configuration with all their links still retained. Not saving the models them selves on your drive, but their positions. Similar how “linking” of primitives worked in SL. The data saved is the primitives in different settings in a single object.

I’ll flesh this one out over the week if piper doesn’t comment on here :wink:


#4

I guess piper simply doesn’t visit the forums that often.
In anycase:

One of the ways how in-world tools would be to use repeated objects to define a scene. For example using a pre-made pillar mesh, or basic boxes to create a house.

Right now what we are missing is grouping of multiple objects:

While this will at some point exist, we should expand on this, we should have the native ability to save a group of entities. into a json format (with all their settings and reference) and / or read json format to construct groups of entities. Reading the format would work similarly to scripts, but instead of running forever, it would just rez the configuration of objects onto the scene.

Currently on scripts, this is fully doable, as in parsing json is something natively done in javascript (After all its Javascript notation language), However we have no way to actually save these information. This way we could also create entities that spawn groups of objects.

As a rule however, you cannot save a json configuration if you are not the owner of the entity group.


This will however lead to the question of inworld tools, with such an ability to save/load entities:
I have an unpopular opinion on this, but please heed this warning: If we will include primitives in client (locally instead of making the content creators to make their own components) they should be very basic shapes and should be ultra light in polygon use, No-where near the amount of polygons they use in SL. Another question that would rise from this what is too many entities in a domain (has anyone tested this? with mesh you can save quite alot in entity count within a domain)

I personally found primitives, while basic, and very easy to build with, were redundant polygon waste just to allow custom ability of each prim component. Most of the polygons are not even seen as most faces get hidden by other primitives.

Id rather return the voxels based inworld tools, and improve upon them to be akin to Everquest landmark than: These could be utilized with a bit more flexibility for basic primitive building, and would make sure on topology of objects is optimized to some degree with LOD (also with posibility to destroy perhaps? I am going over my head though). Ofcourse, thatd be a huge amount of extra work.

The restrain of server bandwidth use would also encourage the use of them instead of optimized meshes.