YafaRay future roadmap. Are you have a list?

[odil24]

Hi David. Are you listed roadmap for future development? New features? Bug fixe? We are interested in. :)

[DavidBluecame]

Hello,

The first objectives I have are needed in my opinion before adding any new features, because now the code is difficult to maintain. Also the current library API is too open, so we are constrained when we want to make changes because any fundamental changes to the code would break the API. I intend to reduce the scope of the API so we are free to make bigger changes to the code.

To address a new reduced API, I need to focus on changing object parameters in runtime which is not possible now and I'm in the process of implementing. For example to read/change the properties of an object in python without having to re-create the entire scene or to access low-level objects.

Another issue we had for many years is that the parameters available to the different objects are not clearly defined nor documented. I intend to create a "properties" interface that will allow users to fetch, in runtime, a list of the properties of an object and a small description of each, allowing the user to get their values and modify them, as well as to alert the user if it passes a parameter to the object that is not in its properties list (and therefore will be ignored).

If I can implement an easier "name-oriented" way to create and modify objects in runtime without the need to access the internal object pointers, I can restrict and cleanup the API to avoid direct access to the objects.

At the same time I'll try to clean up some of the code, making it a bit more modern as most of it was programmed using old pre-C++11 paradigms.

Another requirement for a smaller and cleaner API is to get rid of the plugins system, as the plugins need access to a wide core api. I plan to integrate all classes/subclasses into a single library without plugins, same as the pbrt v2 and v3 did.

All that involves a lot of work, just to improve the code quality, consistency and to allow a smaller and better defined API.

The next step after the code is ready to start implement some kind of dual LGPLv2.1+ and LGPLv3+ licensing that can be chosen with a CMake option, so even if the libYafaRay core code is LGPLv2.1+, we can enable LGPLv3+ parts of the code to allow using Apache v2 dependencies such as Embree and others.

With the above we can start adding such dependencies and extend libYafaRay with more features.

I also hope that making the code a bit cleaner, more consistent and easier to maintain will allow other programmers to join in the future, because my time (and energy) is very limited when I can do some work on YafaRay...

Best regards.

[odil24]

All are these very interesting and promising. Ok, we will just wait and wish you best on development, of course, in your real life too😉

Best wishes.

[DavidBluecame]

FYI an update: I'm currently preparing the following in parallel:

• New libYafaRay v4. No feature changes for now, but huge changes to the code base and interface, hoping to make it easier to understand and maintain. Still working on this. Once I reach a stable code (still far from it), I'll start implementing new features.
• YafaRay-Blender: adapting it for the major changes in libYafaRay v4
• YafaRay-Blender (blender29 branch): very experimental branch for Blender 2.90 and using libYafaRay v4. It loads in Blender v2.9 but many things not yet working. One of the reasons behing the major changes I'm making to libYafaRay v4 is to try to create the interface and features needed for Blender 2.90 integration. Still a lot of work to do, but I'm working on it!

[DionXein]

Hi there. Did you reach/done anything from your task list for now?

[DavidBluecame]

Hello, @DionXein

Actually yes, I've been slowly but steadily working on YafaRay... a bit of dry work, but I've been working on:

• Separating YafaRay in smaller projects: one for the actual core code libYafaRay, and the GUI, Python/Ruby bindings, XML reading, etc, in separate projects with proper dependencies. I'm also re-writing the CMake build scripts to make their building and inter-dependencies easier to handle.
• Redefining the API/ABI for libYafaRay to work as a real library, with a narrow better defined C (not C++) API to get a more stable ABI as well. Still in progress as I find out what features are needed in the API for all the features desired
• Migrating the codebase to more modern C++11 practices and name conventions. This is almost completely done.
• Stabilizing the libYafaRay code to get rid of memory leaks and other corruption bugs. This work will never end but I think I've made a lot of progress.
• I'm now focused on re-defining the Python bindings and the linkage to the new libYafaRay API/ABI. I've got rid of SWIG for generating them, that should make all easier to build and debug.
• My intention now is to set up the new Python bindings so I can connect again the original Blender Exporter for Blender 2.79 (with some changes to adapt for the new API/ABI). I'm working on this now.
• Once I have the new Python bindings and Blender Exporter 2.79 working, my plan is (at last!) to start defining any new/modified API functionality to achieve proper material node handling and (I hope) a more optimized rendering of modified scenes.

So it is a lot of work behind the scenes without any apparent improvements for users (yet). But I hope that I'm reworking the foundations so it allows better development of actual features in the future. Keep in mind that the code base was very old, made by quite different people with different mindsets and a lot of "patches" on top of each other. It was very difficult to understand and maintain and although I still have a lot of work to do in front of me, I hope to be untangling it little by little.

I hope this answers your question. I'm sorry I cannot work faster, I only have the time and energy I have at the end of the day to work on YafaRay, but I'm still working on it.

[DavidBluecame]

I did not mention that once I have a proper material node handling in place, I will be able to start developing properly a Blender 2.8x/2.9x (or perhaps Blender 3.x?) interface. A big road block for that was the lack of proper material node handling in YafaRay. That's still to be developed but I hope I can do it after I finish all this "foundations rework"

[DionXein]

I did not mention that once I have a proper material node handling in place, I will be able to start developing properly a Blender 2.8x/2.9x (or perhaps Blender 3.x?) interface. A big road block for that was the lack of proper material node handling in YafaRay. That's still to be developed but I hope I can do it after I finish all this "foundations rework"

Thank you for so detail answer!
Sounds like titan work already done - and a lot of work should be done next.
I have a few questions - is it reasonable to adapt Yafaray to Blender 2.7?
And am I get it right - for now only you alone work on Yafaray? And if so - may I ask - what knowledge would have ppl to give some help in your journey? (I mean C++ 11, python 3.9)

[DavidBluecame]

Hi, yes, it's been quite a lot, but I understand that all this work is behind the scenes and barely noticeable by any users who are expecting new releases and features. I hope those are not too far in the future now.

About adapting YafaRay to Blender 2.79 the reason is because before all this rework it was the only fully functional Blender exporter for YafaRay. So after reworking the foundation, API, ABI and bindings, it makes sense to adapt the full Blender Exporter for Blender 2.79 for the new libYafaRay API, etc, to make sure that all is still working correctly now after all the changes.

After the exporter works again with the new system, I'll start working on adapting it for the latest Blender, including adding/modifying any necessary API functions for it, including working on the nodes system.

At this moment, because the work is so fundamental and big in scope, I think it's better that I continue doing it myself. However one of my objectives with all this work is to "sanitize" the code base to attract more developers to YafaRay in the future, hoping that the new code base is better organized and not so scary as it was (at least to me) in previous versions.

In the future when the new YafaRay 4 "suite" made of several interconnected libraries is ready and has a stable API/ABI, then we might discuss the possibility of new developers contributing code. Knowledge necessary will be of course C++11 and Python >=3.5, although the necessary knowledge level might be debatable.

Thanks and best regards.