AlexRyder

This looks pretty awesome, but I'll copy a little suggestion from another topic
 
Since obviously you will be modifying the save file format, it would really benefit from using compression — you already have an Ionic.Zip.dll library in your assemblies folder, so it would be very easy to zip-compress the files before base-64 encoding and uploading them to the server (probably instead of encrypting them, which kinda makes no sense since they're available to everyone anyway). Some of the large user rooms can be a couple of Megabytes in size uncompressed, while in compressed format they may be reduced in size 10–20 times. Heavy rooms are known to cause downloading lag for some users, and compressing them would also reduce the server load as well.
 
If you intend to keep compatibility with already existing user room files, it's also pretty easy to distinguish the old and new formats by the file header or something like that.
 
Also, in the current code you have a lot of manual xml file processing which is far from optimal at best, while .NET by default has a pretty powerful built-in xml processing tools, which are faster. Or at least when reading individual tags, you shouldn't edit the source string every time like it is done now (something like "<data> + txt + <data>"), when there are a lot of objects, those extra concatenations may take forever.

Is it the "Runtime Editor" by Vadim Andryanov you're basing the World editor on? Looks very like much it, but I'm not quite sure... But the gizmo handles are certainly from this publisher
https://assetstore.unity.com/packages/tools/modeling/runtime-editor-64806

Why not keep the old 2 rooms (upgrading the save files to the new format) and add the empty space as a third one?

Why not keep the old 2 rooms (upgrading the save files to the new format) and add the empty space as a third one?

Is it the "Runtime Editor" by Vadim Andryanov you're basing the World editor on? Looks very like much it, but I'm not quite sure... But the gizmo handles are certainly from this publisher
https://assetstore.unity.com/packages/tools/modeling/runtime-editor-64806

Why not keep the old 2 rooms (upgrading the save files to the new format) and add the empty space as a third one?

Why not keep the old 2 rooms (upgrading the save files to the new format) and add the empty space as a third one?

I have been playing around with adding full browser and video support to 3dx, lol O:)
I've tried using Awesomium with a modified AwesomiumUnity as the base engine, but the major issue with it is that Awesomium is so seriously outdated it has problems opening web sites. Was thinking of integrating CEF (Chromium Embedded Framework) instead and playing videos using VLC libraries, but hasn't had time to try it...
The main idea was to have support for most of the well-known video sites and for the videos to be synchronized across users (i.e. if the room host changes the video position, it should be set accordingly for everyone in the room, etc.), and that is not possible for every site, but should be doable with VLC.
 
https://i.imgur.com/Gg2RWOp.png
https://i.imgur.com/kL8dJi2.png
 
A little preview, be wary it may have some porn in it. Also, the recording is kinda laggy
https://www.youtube.com/watch?v=G-YNOOPIv5M
 
Unity has built-in video support since version 5.6, but its features for online playback seem to be pretty basic...

Awesome! 

This looks pretty awesome, but I'll copy a little suggestion from another topic
 
Since obviously you will be modifying the save file format, it would really benefit from using compression — you already have an Ionic.Zip.dll library in your assemblies folder, so it would be very easy to zip-compress the files before base-64 encoding and uploading them to the server (probably instead of encrypting them, which kinda makes no sense since they're available to everyone anyway). Some of the large user rooms can be a couple of Megabytes in size uncompressed, while in compressed format they may be reduced in size 10–20 times. Heavy rooms are known to cause downloading lag for some users, and compressing them would also reduce the server load as well.
 
If you intend to keep compatibility with already existing user room files, it's also pretty easy to distinguish the old and new formats by the file header or something like that.
 
Also, in the current code you have a lot of manual xml file processing which is far from optimal at best, while .NET by default has a pretty powerful built-in xml processing tools, which are faster. Or at least when reading individual tags, you shouldn't edit the source string every time like it is done now (something like "<data> + txt + <data>"), when there are a lot of objects, those extra concatenations may take forever.

This looks pretty awesome, but I'll copy a little suggestion from another topic
 
Since obviously you will be modifying the save file format, it would really benefit from using compression — you already have an Ionic.Zip.dll library in your assemblies folder, so it would be very easy to zip-compress the files before base-64 encoding and uploading them to the server (probably instead of encrypting them, which kinda makes no sense since they're available to everyone anyway). Some of the large user rooms can be a couple of Megabytes in size uncompressed, while in compressed format they may be reduced in size 10–20 times. Heavy rooms are known to cause downloading lag for some users, and compressing them would also reduce the server load as well.
 
If you intend to keep compatibility with already existing user room files, it's also pretty easy to distinguish the old and new formats by the file header or something like that.
 
Also, in the current code you have a lot of manual xml file processing which is far from optimal at best, while .NET by default has a pretty powerful built-in xml processing tools, which are faster. Or at least when reading individual tags, you shouldn't edit the source string every time like it is done now (something like "<data> + txt + <data>"), when there are a lot of objects, those extra concatenations may take forever.

I have been playing around with adding full browser and video support to 3dx, lol O:)
I've tried using Awesomium with a modified AwesomiumUnity as the base engine, but the major issue with it is that Awesomium is so seriously outdated it has problems opening web sites. Was thinking of integrating CEF (Chromium Embedded Framework) instead and playing videos using VLC libraries, but hasn't had time to try it...
The main idea was to have support for most of the well-known video sites and for the videos to be synchronized across users (i.e. if the room host changes the video position, it should be set accordingly for everyone in the room, etc.), and that is not possible for every site, but should be doable with VLC.
 
https://i.imgur.com/Gg2RWOp.png
https://i.imgur.com/kL8dJi2.png
 
A little preview, be wary it may have some porn in it. Also, the recording is kinda laggy
https://www.youtube.com/watch?v=G-YNOOPIv5M
 
Unity has built-in video support since version 5.6, but its features for online playback seem to be pretty basic...

You could probably have some kind of a "Material slots" list in the world editor (working like the user gallery or something) where users could create their custom materials from some basic presets (like metal, stone, glass, cloth, etc.) and upload their own textures, this way it would be possible to check image size and dimensions first. You can have limitations on image size and dimensions in pixels (probably different based on whether a texture is supposed to be tileable or not). It would also be pretty cool if users could upload their own diffuse, bump and opacity maps those custom materials.
There is a lot of stuff that can be customized even with the default Unity's shader, so the materials can also have sliders for some of the properties (opacity, reflectiveness, shininess, etc.).
 
Also, there could be a resizable "framed picture" object where people could place their own images, this feature has been asked about a lot
 
As for the performance of having a lot of user textures, some kind of beta-testing will most likely be required to find out reasonable limitations, there are a lot of room builders out there who I'm pretty sure will be more than happy to participate in the testing

You could probably have some kind of a "Material slots" list in the world editor (working like the user gallery or something) where users could create their custom materials from some basic presets (like metal, stone, glass, cloth, etc.) and upload their own textures, this way it would be possible to check image size and dimensions first. You can have limitations on image size and dimensions in pixels (probably different based on whether a texture is supposed to be tileable or not). It would also be pretty cool if users could upload their own diffuse, bump and opacity maps those custom materials.
There is a lot of stuff that can be customized even with the default Unity's shader, so the materials can also have sliders for some of the properties (opacity, reflectiveness, shininess, etc.).
 
Also, there could be a resizable "framed picture" object where people could place their own images, this feature has been asked about a lot
 
As for the performance of having a lot of user textures, some kind of beta-testing will most likely be required to find out reasonable limitations, there are a lot of room builders out there who I'm pretty sure will be more than happy to participate in the testing

You could probably have some kind of a "Material slots" list in the world editor (working like the user gallery or something) where users could create their custom materials from some basic presets (like metal, stone, glass, cloth, etc.) and upload their own textures, this way it would be possible to check image size and dimensions first. You can have limitations on image size and dimensions in pixels (probably different based on whether a texture is supposed to be tileable or not). It would also be pretty cool if users could upload their own diffuse, bump and opacity maps those custom materials.
There is a lot of stuff that can be customized even with the default Unity's shader, so the materials can also have sliders for some of the properties (opacity, reflectiveness, shininess, etc.).
 
Also, there could be a resizable "framed picture" object where people could place their own images, this feature has been asked about a lot
 
As for the performance of having a lot of user textures, some kind of beta-testing will most likely be required to find out reasonable limitations, there are a lot of room builders out there who I'm pretty sure will be more than happy to participate in the testing

You could probably have some kind of a "Material slots" list in the world editor (working like the user gallery or something) where users could create their custom materials from some basic presets (like metal, stone, glass, cloth, etc.) and upload their own textures, this way it would be possible to check image size and dimensions first. You can have limitations on image size and dimensions in pixels (probably different based on whether a texture is supposed to be tileable or not). It would also be pretty cool if users could upload their own diffuse, bump and opacity maps those custom materials.
There is a lot of stuff that can be customized even with the default Unity's shader, so the materials can also have sliders for some of the properties (opacity, reflectiveness, shininess, etc.).
 
Also, there could be a resizable "framed picture" object where people could place their own images, this feature has been asked about a lot
 
As for the performance of having a lot of user textures, some kind of beta-testing will most likely be required to find out reasonable limitations, there are a lot of room builders out there who I'm pretty sure will be more than happy to participate in the testing

You could probably have some kind of a "Material slots" list in the world editor (working like the user gallery or something) where users could create their custom materials from some basic presets (like metal, stone, glass, cloth, etc.) and upload their own textures, this way it would be possible to check image size and dimensions first. You can have limitations on image size and dimensions in pixels (probably different based on whether a texture is supposed to be tileable or not). It would also be pretty cool if users could upload their own diffuse, bump and opacity maps those custom materials.
There is a lot of stuff that can be customized even with the default Unity's shader, so the materials can also have sliders for some of the properties (opacity, reflectiveness, shininess, etc.).
 
Also, there could be a resizable "framed picture" object where people could place their own images, this feature has been asked about a lot
 
As for the performance of having a lot of user textures, some kind of beta-testing will most likely be required to find out reasonable limitations, there are a lot of room builders out there who I'm pretty sure will be more than happy to participate in the testing

It's not like anyone is forcing you to go there.
And how is it even related to tech support? XD

It's not like anyone is forcing you to go there.
And how is it even related to tech support? XD

Wow, looks like something I was thinking of doing, but still haven't got to %)) Very promising so far 
 
A little suggestion though: since obviously you will be modifying the save file format, it would really benefit from using compression — you already have a Ionic.Zip.dll library in your assemblies folder, so it would be very easy to zip-compress the files before base-64 encoding and uploading them to the server (probably instead of encrypting them, which kinda makes no sense since they're available to everyone anyway). Some of the large user rooms can be a couple of Megabytes in size uncompressed, while in compressed format they may be reduced in size 10–20 times. Heavy rooms are known to cause downloading lag for some users, and compressing them would also reduce the server load as well.

I think it is better to create an invisible "bed" and "wall" placeholder planes (with a visible grip in edit mode like it is done for the fire object, or something like that). Maybe the sitting (sofa) placeholder, too

I think it is better to create an invisible "bed" and "wall" placeholder planes (with a visible grip in edit mode like it is done for the fire object, or something like that). Maybe the sitting (sofa) placeholder, too

This looks pretty awesome, but I'll copy a little suggestion from another topic
 
Since obviously you will be modifying the save file format, it would really benefit from using compression — you already have an Ionic.Zip.dll library in your assemblies folder, so it would be very easy to zip-compress the files before base-64 encoding and uploading them to the server (probably instead of encrypting them, which kinda makes no sense since they're available to everyone anyway). Some of the large user rooms can be a couple of Megabytes in size uncompressed, while in compressed format they may be reduced in size 10–20 times. Heavy rooms are known to cause downloading lag for some users, and compressing them would also reduce the server load as well.
 
If you intend to keep compatibility with already existing user room files, it's also pretty easy to distinguish the old and new formats by the file header or something like that.
 
Also, in the current code you have a lot of manual xml file processing which is far from optimal at best, while .NET by default has a pretty powerful built-in xml processing tools, which are faster. Or at least when reading individual tags, you shouldn't edit the source string every time like it is done now (something like "<data> + txt + <data>"), when there are a lot of objects, those extra concatenations may take forever.

I think it is better to create an invisible "bed" and "wall" placeholder planes (with a visible grip in edit mode like it is done for the fire object, or something like that). Maybe the sitting (sofa) placeholder, too

I think it is better to create an invisible "bed" and "wall" placeholder planes (with a visible grip in edit mode like it is done for the fire object, or something like that). Maybe the sitting (sofa) placeholder, too