Print at Apr 13, 2021, 3:14:13 AM

Posted by Puybaret at Jun 3, 2016, 10:39:56 AM
Re: Export to HTML5 plug-in
I'm glad you found some use for the Home.xml export. Do you plan to make your script available to the public? That would be a nice way to import a home in Blender with lights.

I don't know whether the HTML viewer will support some lighting, but you can already get in Home.xml file the light information you look for by changing some flags in the plug-in source code included in the sh3p file (or reusing plug-in classes in an other plug-in). The easiest way should be to remove HomeXMLFileRecorder.INCLUDE_VIEWER_DATA flag (and HomeXMLFileRecorder.REDUCE_IMAGES if you don't want images to be resized) in the getHomeRecorder method the end of the ExportHTML5PluginAction inner class of com.eteks.sweethome3d.plugin.exporthtml5.ExportHTML5Plugin. Then, rebuild the plug-in with the help of Plug-in developer's guide.

The XML format of Home.xml shouldn't change in the future, it will even become part of the updated format of Sweet Home 3D files. In the coming versions 5.x, the idea is to include the Home.xml file along with the existing Home Java serialized entry in .sh3d files + the ability to parse both entries even if they describe the same com.eteks.sweethome3d.model.Home instance. Then probably in versions 6+, the default Sweet Home 3D files will have a .sh3x extension and use a file format that will contain a Home.xml entry but no Home entry, to avoid slowing down Save operation. This transition will help users to read .sh3x files even with Sweet Home 3D version 5.3 and superior. Of course, the ability to read Home Java serialized entry included in .sh3d files will be kept to be able to read all files made with previous versions of Sweet Home 3D.
The XML writer added to Sweet Home 3D 5.3 will be very close to the one in Export to HTML5 plug-in, using the same elements and attributes syntax when its INCLUDE_VIEWER_DATA flag is not set. Why only "very close" and not "the same as"? Because the plug-in needs to simplify the exported data to match SweetHome3DJS features, i.e. its inability to read 3D models at 3DS and DAE format as well as to compute walls and rooms in 3D. Quickly said, at the moment, the plug-in is "only" able to read 3D models at OBJ+MTL format listed in Home.xml and place them at the good location. Walls, floors, ceilings, holes in the ground and 3D labels are all precomputed by the plug-in in the HomeStructure/Home.obj entry which is displayed as one 3D object by SweetHome3DJS. This structure file and exporting only in OBJ format is not needed in Sweet Home 3D itself, that's why its XML writer will not perform these operations but will keep the same XML syntax, except for the structure attribute of the home.
From the various tests I run with Blender, it seems that Blender supports better OBJ+MTL format than 3DS and DAE formats (but maybe it was improved recently). Blender is of course unable to compute in 3D the walls and rooms of a Sweet Home 3D file. So I guess that the format I chose for SweetHome3DJS is the best choice for Blender too, and you would prefer that the way 3D models and home structure are exported won't change! I'll keep that in mind and if needed I'll create an other Export to XML + OBJ plug-in. That could even become a Save option in Sweet Home 3D if this format becomes really useful for many people. Keep also in mind that DAE/Collada format is also able to store lights, so if you need only OBJ files + lights, it could be more logical to add Export to DAE format option (even if this will require more work from me).
Emmanuel Puybaret, Sweet Home 3D developer