Dev talk:Ref/Design docs/Render API/Renderer
One might look into integrating with my plugin-system workover. Should at least solve basic decisions, how the render plugin can talk to the GUI, in which way we detect our export plugins etc.
--Peter Schlaile 17:20, 3 June 2007 (CEST)
Hi Peter, thanks for the comment. I've got a few questions though. Your page says "Looking at the gimp plugin system, the best way to do this (for speed reasons): scan once and cache the result until the plugin filestamp changes again." Is this already implemented? If so, how is the caching done, and what folder is the scan folder? Are there specific files I should look at?
email: two.a.ron (at) gmail (dot) com
--Mosani 07:12, 4 June 2007 (CEST)
Hi Aaron. Scanning is implemented. Currently, two directories are specified in the user preferences for sequence plugins and texture plugins. I scan both. One could add a third directory for render plugins or change the whole thing to scan a list of directories. Open for discussion.
Currently, the code can scan the directories and write the information to a cache file within the ".blender" directory in the user's homedir. I copied the code from the python-menu-code. If the cache file already exists, I use it blindly, timestamp checking is not done yet, but could be added easily.
However: we will need a manual rescan button in any case. Reason: plugins can provide access to other plugin structures as gstreamer - and then simply timestamp checking will fail anyways.
One should also note, that this is very much work in progress. The code compiles, but is not used in blender anywhere right now.
"Are there specific files I should look at?" Maybe take a look at the "PLU_api.h" and "PLU_types.h", they should explain everything to the users of the system. (core and plugin-side)
To integrate render-api, you should add a PLUGIN_TYPE_RENDER_OUTPUT, and specify a corresponding struct plugin_interface_render_output for the interface, the core is supposed to use.
If you need functions, your plugin should call, please add them to PLU_api.h using LIBEXPORT prefix, to get them exported to the plugin.
Currently, capabilities are stored in a 64bit integer, so there is room for 64 different capabilities. If you think, we need an arbitrary number of those, we could still choose to use another data type. (However, I personally don't think, that will be necessary...)
If you have further questions or suggestions regarding my plugin system, feel free to ask!
--Peter Schlaile 09:33, 6 June 2007 (CEST)
Hi Aaron.
It is not totally clear to me, in which way you are "deviating" from my plugin system. My goal was to have _one_ plugin system for blender. If you need extensions to the system, please let me know.
(I read the wiki-page. Not having a GUI is no deviation. It is intended behaviour, that you can register a GUI structure seperately. You also do not have to change the head of the plugin_descriptor structure itself. Just add your interface structure to the interface-union within the plugin_descriptor. Again, this is no deviation, but intended behaviour.)
--Peter Schlaile 12:58, 30 June 2007 (CEST)
Hey Peter,
I changed the page. The UI point... you're right, it isn't really a point. However, the Renderer struct is not something I wish to simple remove, for the reasons I talk about in the new page.
--Mosani 02:27, 12 July 2007 (CEST)
