Page 5 of 9

Posted: Fri Mar 11, 2005 2:59 am
by simonharvey
mjordan wrote:What does it mean? The ocean simulator is dead? :cry:
I am currently coding a framework for simulations that will allow developers to write plugins and have them interact with geometry.

So far I have written the API registry (for exporting blenders internal API to the external modules) and also other stuff. Bits of it are going to have to be redone but it is going along well.

I think that there has been a communication breakdown: My intentions are not to replace the OOPS schematic, but to recycle some of the code so I don't have to rewrite the schematic editor of my project.

I am currently doing this at my own time, at my own pace so it will be erratic, but my goal is to get something finished that has a future and is consistant with the rest of blender.

I will post updates on this thread, so if I have made any progress then you know where to look.

Kind Regards
Simon Harvey

Posted: Fri Mar 11, 2005 3:50 am
by levon
if you need any help testing, i can compile my own blender windows binaries if you suply me with a patch file.

cant wait to see it working :D

Posted: Tue Apr 05, 2005 4:30 am
by simonharvey
Hi everybody
This is just a little update to tell you where I am at and where I am going.
As I have mentioned in another post due to difficulties in extending blender I am writing a new plugin framework to make it easier for developers (who code in C, C++) to write extensions for it.

Right now I am working on the core functionality, such as memory, file IO, API and module registries. I am also making it thread friendly so that even though the main blender application is a single threaded program, the modules don't have to be.

Unfortunetly it is pointless to get a screenshot of this stuff since it is very behind the scenes, however when blender loads up I am thinking of putting a progress bar at the botom of the splash screen to tell the user off the extensions that are being loaded (just like in Maya and 3D Studio Max).

Currently my OceanFFT code is being ported to the extension framework (as a Blender Module eXtension "BMX") and is being used as the reference plugin. So it is still there, but it will require more time before it is released into the wild.

I am currently adding (on average) about 10 lines/day so please dont think that the OceanFFT project is dead, it has been generalised a bit to allow others to easily add mesh effects/texture types by integrating their code within a streamlined framework.

Kind Regards
Simon Harvey

Posted: Tue Apr 05, 2005 4:56 am
by mjordan
Wow I have always dreamed a thing like that!!! This would be a great improvement for Blender.
Do you think all this stuff is going to replace python scripting one day?
Hope all this stuff will bring Blender to have a clean way of developing new extensions in a "integrated" way...

Posted: Tue Apr 05, 2005 7:20 am
by levon
mjordan wrote:Wow I have always dreamed a thing like that!!! This would be a great improvement for Blender.
Do you think all this stuff is going to replace python scripting one day?
Hope all this stuff will bring Blender to have a clean way of developing new extensions in a "integrated" way...
it will never 'replace' python, but i think it will replace the texture plugins, and posably the sequencer plugins and maybe even effects (waves etc.)

python is strong as a scripting language(yes i know technicaly python isnt a scripting language), which isnt the case with this new blender format, they both are aimed at different uses.

Posted: Tue Apr 05, 2005 9:48 am
by kencanvey
This sounds like it will be a great tool for Blender and the community of users.

Thank you for your continuing work Simon.


Posted: Tue Apr 05, 2005 2:37 pm
by harkyman
I'd like to second that encouragement. You're doing a great thing for Blender that will pay dividends in artistic production for years to come.

Keep it up.

Posted: Tue Apr 05, 2005 3:14 pm
by levon
it would a good idea to start talking with ton and other coders about this project, and like ive said before the mailing list is probably the best place for it. and other then that the #blendercoders IRC channel is good to talk in real time with coders.

if you want i can start forwarding your posts here to the mailing list and post the comments back here if your not into the idea of using the mailing list.

great work :D

Posted: Tue Apr 05, 2005 10:28 pm
by Dani
oh boy!

good good! I join to the others! this is a great project!
if you need testing, I'll be happy to help!


Posted: Thu Apr 07, 2005 10:41 pm
by gendou
Hi, I would also like to post my encouragement and thanks to you for developing a real plugin API. This is something blender has needed for some time, but I'm guessing that with other feature development, the main coders don't have time for something like this. Python, though serving well in the past and present, isn't the same as plugins for other programs, which show up with the base tools in other packages. This may also encourage 3rd party plugin developers to include blender on their lists of supported apps. I think that many blender users would pay for commercial plugins and this API would be part of the bridge between blender and "professional" status.

thanks again

Posted: Mon Apr 11, 2005 8:17 am
by simonharvey
Right now the modules use Win32 styled messaging to preform operations, i.e. to return a texture sample at a point it will return a texture sample to a TEXTURE_SAMPLE message, the modules callback is shown below:

Code: Select all

void * callback(BlenderModule * mod, unsigned long msg, void * pointer, long value); 
Included in the callback is a switch statement that is used to decipher what is to be executed, and if a message isnt implemented then a default callback is called. This was chosen over straight callbacks for extensibility (since I know only loosly what I need to implement).

When the plugin is first loaded the following functions are found:
unsigned short module_stat(char val): returns pointer and integer widths.
void * module_reload(GUID * guid): [optional] if this is contained the module is considered swapable meaning that if all references to it are zero then it can be unloaded from memory (saving memory), this function is handed a GUID (after the modules has been loaded up again) and returns a pointer to the module's callback function.
HRESULT module_init(BlenderInit * init): this function gets called after it has been loaded, the BlenderInit structure contains a reference to an BAPI structure that contains (as function pointers) the minimal amount of functionality to manage a module and to obtain exported functionality via it's HRESULT getAPI(char * name, void **) method.

You will notice the use of messages, HRESULT codes and GUIDS. I have chosen to include these because they are of sufficient weight to allow massive expansion of the basic blender codebase and are respected in other fields of programming.

That is going to have to be it for now,
Kind Regards
Simon Harvey

Posted: Wed Apr 13, 2005 5:21 pm
by Money_YaY!
is it useless to hope that this will get built ?

Posted: Wed Apr 13, 2005 6:04 pm
by DYeater
Money_YaY! wrote:is it useless to hope that this will get built ?
As long as you're seeing activity on the subject, it isn't hopeless.

Posted: Thu Apr 14, 2005 6:25 am
by simonharvey
Money_YaY! wrote:is it useless to hope that this will get built ?
It is going to get built hovever I am writing something from scratch and not making an adition so the dynamics are different. Starting from the beginning is always more difficult since there is no 'rolemodel' to base it off (and if there is I purposely havent looked at it in order to avoid intellectual property issues with the creators of other 3d modelling programmes).

It is going to be built but development is preceeding slowly because I am halfway through my Masters thesis writeup.

Please have patience.

Kind Regards
Simon Harvey

Posted: Wed Apr 20, 2005 6:07 am
by antihc3
Hey Simon I was just wondering if you where still working on the C/C++ plugin system??