@keet the concept which YGYL is trying to describe is the same of grouped furniture. SH3D is already capable of handlig this, but lacks the ability to copy this group in the catalog for future use.
Of course you can export the group as a single object and import it in the catalog, but this will be no longer editable and will take more space, since all vertex coordinates have been copied in the new model.
Furniture groups instead don't take up space, because they are just a list of references to existing models along with spatial information about where they should be placed in the plan.
Even in the case where this new kind of object would camepackaged in a furniture library along with vertex data, there is a chance to save space. Think about a group made by a table with 6 chairs: you could have vertex data for the table alone and for a single chair, then the group will say to duplicate the chair model around the table, but this happens at runtime, so only one chair model is actually taking space on the disk.
Aha, that's a different kind of concept and I like the idea! In a way it is a different kind of storage for the objects in a sh3d project that could potentially save a lot of disk space. Now I'm not sure that saving disk space is all that important with the current cheap storage per MB but for some devices with limited disk space it might be a great advantage. Of course you can export the group as a single object and import it in the catalog, but this will be no longer editable and will take more space, since all vertex coordinates have been copied in the new model.
Furniture groups instead don't take up space, because they are just a list of references to existing models along with spatial information about where they should be placed in the plan.
Even in the case where this new kind of object would camepackaged in a furniture library along with vertex data, there is a chance to save space. Think about a group made by a table with 6 chairs: you could have vertex data for the table alone and for a single chair, then the group will say to duplicate the chair model around the table, but this happens at runtime, so only one chair model is actually taking space on the disk.
What would be a huge advantage is if the 3D processing of the project uses that same concept by loading that single model and replicates it in multiple positions. It's what what I indicated with comparing it to object oriented programming: one object definition and create multiple instances for usage in the project. It would mean that the vertex/face data must be calculated when processing the instances by using the object and the defined size/position. I suppose the math is already available in game engines. I have no idea if it is faster with the 3D display.
I have one project in progress where this would have an incredible impact: a stadium with 10.000+ seats. I already optimized this partly by grouping seats and running them through Blender to merge groups and then repeat the same for rows. Imagine the impact of defining a single seat and 10.000+ positions instead of 10.000+ seats! The project would shrink from 300+ MB to just a few MB's
I'm not sure this should be something along the concept of a furniture library. I see it more as a different way of storing objects in a sh3d file. If you add a model that is already in the project then don't add the model again but store a reference with size and position. The way this could be organized could be by using the idea of a furniture library but one that is created inside the sh3d file, not a sh3d file in a furniture library. Every model in the plan is a reference to a model in the internal library with a size and position. The potentially most important advantage is much faster 3D processing. Personally I don't care about disk space although it adds up fast with all the backups I have of 150+ projects and 2000+ custom made models on multiple devices.
----------------------------------------
Dodecagon.nl
1300+ 3D models, manuals, and projects
