Several rendering engines in the same plugin

[enkonyito]

To date, Sweet Home 3D default rendering engine is SunFlow (written in Java).
The YafaRay rendering plugin offers another rendering engine (written in C++ and accessible in Java Native Interface).

Grouping these 2 rendering engines in one plugin with a selector seems like a good idea.


1st problem
For YafaRay rendering to work when selected, you must apparently respect the order and name of the initial com/eteks/sweethome3d/plugin/yafarayrendering packages.
In this case, the [font=courier new]YafarayRenderer.h[/font] and [font=courier new]YafarayRenderer.cpp[/font] files do not appear to be necessary but use the [font=courier new]lib[/font] folder containing the DLLs (Windows, Mac OS X and Linux).
- Solution #1:
In the plugin project folder, use the com/eteks/sweethome3d/plugin/yafarayrendering packages for all files (photo panel, SunFlow and YafaRay rendering engines).
This is a problem when adding another rendering engine where you will also have to respect the order and the name of the initial packages.

- Solution #2:
In the plugin project folder, keep the package created for the SunFlow rendering engine and the photo panel.
Use com/eteks/sweethome3d/plugin/yafarayrendering packages for the [font=courier new]YafarayRenderer.java[/font] file by adding an

Code: Select all

import com.eteks.sweethome3d.plugin.yafarayrendering.YafarayRenderer

in the [font=courier new]PhotoPanel.java[/font] file.
In this case, each rendering engine has its own packages and this would facilitate future additions.


2nd problem
When you press the Stop button, the YafaRay rendering is not interrupted when it is selected.

Enko Nyito

[enkonyito]

2nd problem
When you press the Stop button, the YafaRay rendering is not interrupted when it is selected.

Solution:
Take into account the different management of the Stop button by the YafaRay rendering plugin (YafarayPhotoPanel).

[Puybaret]

[font=courier new]YafarayRenderer.h[/font], [font=courier new]YafarayRenderer.cpp[/font] and any source files like Java ones are not necessary for a plug-in to work. I just took the habit to include source code in the plug-in to avoid developers to download it from another place (these files are generally not very large).
SunFlow and YafaRay renderers are completely independent from each other, so you can organize the packages where you use them like you want.
The only thing to take care of, is too update in the YafaRay program according to where the DLLs it requires are stored, so the plug-in can find these DLLs to extract and load them.

[enkonyito]

How to reduce the size of the plug-in (12 MB) to speed up uploading?

[Puybaret]

In the Beta 4 version of YafaRay plug-in where I recompiled YafaRay DLLs, I already removed many options to make its DLLs smaller. Not sure, I can do better. By the way, once added the DLLs for 32 bit systems, the size of the plug-in will be even twice as large.
The only way I can think of to reduce the plug-in size, would be to produce one plug-in per operating system / architecture, but I'm not sure that it will be as easy to maintain, distribute and explain. We could say it's the weight of portability!

[Puybaret]

Sorry, I forgot about the DLLs found in [font=courier new]yafaray-plugins[/font] folder. It should be possible to remove the ones which are not used: list the values associated to all the parameters named [font=courier new]"types"[/font] in the program, and remove the DLLs which doesn't match the found names. But this might be more complicated that this, because libjpgHandler and libpngHandler DLLs must be kept to support JPEG and PNG of texture images. There might be other dependencies that will need a deeper study.

[UbuntuBirdy]

In my opinion, in 2020 12MB is not large enough to even think about reducing size...

[Puybaret]

Useless bytes are never welcomed so if the plug-in size could be reduced easily, it would be a nice gain.
By the way, larger DLLs means also more time to extract and load them at the launch of the first rendering.

[UbuntuBirdy]

Useless bytes are never welcomed so if the plug-in size could be reduced easily, it would be a nice gain.
By the way, larger DLLs means also more time to extract and load them at the launch of the first rendering.

Correct! But, it's the wrong priority to search for useless bytes while the plug-in is not fully functional yet.
And it's totally the wrong priority if the plug-in is 12MB and not 120MB.
But as written bevore, this is only my opinion...

[enkonyito]

About the integration of the YafaRay rendering engine.


Photos panel at points of view.
The name of the selected rendering engine is added at the end of the image file name.
No particular problem.


Video panel.
The name of the selected rendering engine is added at the end of the video file name.
The video shows a frozen image with the YafaRay renderer while the sequence is animated with the SunFlow renderer.
The following warnings are returned after the first image rendered:

Code: Select all

WARNING: Environment: Sorry, Background "background" already exists!
WARNING: Environment: Sorry, Light "sun" already exists!
WARNING: Environment: Sorry, Camera "camera" already exists!".