[of-dev] addons, addons locatoins

Memo Akten memo at memo.tv
Mon Jul 12 17:18:29 PDT 2010


Hey all, regarding my addons, I see that that the doc is pointing to my google code, which is quite old now and out of date. I've now switched over to github (my google code page has links all over the place linking to github).

http://github.com/memo/msalibs

On most of my addons (mostly the ones involving mainly processing data), i've tried to make them as host independent as possible so they can be used anywhere. Mostly the only things tieing it to OF were the vector types. So now I have an MSACore which is used by pretty much all of my classes, which map the data types and some basic functions across, so now the same addons can be used in openFrameworks and Cinder (and QC and anything else with just a few additions to MSACore). The API's for them hasn't changed, usage is identical (except instead of instantiating ofxShape3D you instantiate MSA::Shape3D, and the rest is the same). 


When I saw on the Cinder forums that they had MSAFluid running 100% faster I had to try it out. They had made some major changes in the solver (combining u[] v[] into uv[], lots of cache optimisations). So I ported it back to OF, and made it OF/Cinder independent by introducing MSACore. And it's true, it is running exactly 100% faster than the previous version, even in OF too! So that's great news. I managed to optimize it to get another 20% out of it by combining r[], g[], b[] into rgb[]. So now with the MSACore system it's easy to maintain a Cinder version and OF version. In fact it's just the exact same MSAFluid for both (And same with MSAPhysics etc.)


However there are two very interesting observations regarding Cinder vs OF:

1. You can see FluidSolver is using MSA::Vec2f and MSA::Vec3f. When I use ofxVectorMath. i.e. typedef ofxVec2f Vec2f; The fluid is very unstable and is extremely prone to exploding. I.e. within a few seconds of using it everything goes bonkers my velocity field explodes. When I use the Cinder data types in OF, i.e. typedef ci::Vec2f Vec2f; (I put a very cut down version in MSACore/cinder-lite) then it runs very stable and as predicted.


2. I measure the performance with the code below

Timer timer;
const int ITERS = 3000;
timer.start();
for( int i = 0; i < ITERS; ++i ) fluidSolver.update();
timer.stop();
cout << ITERS << " iterations took " << timer.getSeconds() << " seconds." << std::endl;

Timer is my class and is very accurate
http://github.com/memo/msalibs/blob/master/MSATimer/src/MSATimer.h
(actually the built in Cinder Timer gives the exact same results as my timer, using the same API I think).

In openframeworks this takes about 14.5 seconds (using the ci::vector types). In Cinder it takes 10.5 seconds! FluidSolver.cpp is IDENTICAL in both apps. FluidSettings are identical in both apps. I cannot figure out how there can be 40% performance difference between Cinder and openFrameworks in a scenario like this. It isn't anything to do with drawing, or glut, update loops or anything. Just pure processing. Must be compiler settings or something? (my OF project is based on the allAddonsExample and Cinder project is created by TinderBox).

One for you hardcore folks out there :)



	
Studio 107. 7 Westgate St. London E8 3RL
mob: +44 7958 783 832
tel: +44 20 8123 9986
fax: +44 20 8986 5496

work: www.msavisuals.com
play: www.memo.tv


On 10 Jul 2010, at 01:17, Kyle McDonald wrote:

> Amazing list! I was trying to remember the name of ofxFreeFrame recently...
> 
> I have an idea for /addons, I might have mentioned it here before: make it entirely user (developer) generated. On the /addons page, there will be a form with a single text field. In that text field, you submit a URL. The URL points to an XML file that looks like this:
> 
> <?xml version="1.0" encoding="UTF-8"?>
> <addon>
> <title>ofxControlPanel</title>
> <addonUrl>http://github.com/ofTheo/ofxControlPanel</addonUrl>
> <author>Theo Watson</author>
> <authorUrl>http://theowatson.com/</authorUrl>
> <description>A flexible control panel based GUI, with XML saving and a variety of input types.</description>
> <lastUpdated>
>  <date>17</date>
>  <month>6</month>
>  <year>2010</year>
> </lastUpdated>
> </addon>
> 
> The server grabs this file and adds the info to an internal database. The server updates itself automatically once a day, giving authors the ability to change their project description or project url.
> 
> I think the Processing model is great:
> 
> http://processing.org/reference/libraries/
> 
> And the main thing it's missing is some information about things that might not work anymore (though they did some pruning when 1.0 was released). This is why I included the lastUpdated field above.
> 
> Maybe even steal the Processing categories (3D, animation, compilations, cv, data/protocols...) for /addons?
> 
> Curating addons will make the page really useful, but I think the addon scene is almost too volatile. Unless someone is regularly maintaining /addons it could quickly lose its utility.
> 
> Again, awesome work :)
> 
> Kyle
> 
> Zachary Lieberman wrote:
>> greetings everyone! in the middle of this crazy heat spell, my crew here in nyc has been going through and finding addons to add to the page: openframeworks.cc/addons/contributed <http://openframeworks.cc/addons/contributed>
>> we've started a very rough list here of things we've found.  There's some very interesting stuff out there, and I'm sure as we get deeper into this, it will help alot: http://piratepad.net/1TwSWduAae
>> I particularly enjoyed spotting ofxToxi ;) In addition, we'd like to remove / decommission / (nuke!) addons.openframeworks.cc <http://addons.openframeworks.cc>, which isn't really working as we had intended last year, and encourage anyone that's got stuff on there, to get it off on to google code, github, or their own site.  There is a list, on the piratepad towards the bottom, of addons that are on the contributed page that link to the addons.openframeworks.cc <http://addons.openframeworks.cc>.    We'd like to try to get stuff out of there by next week, and will ping individual authors if necessary.  We're checking now if they've moved, and will update the pirate pad as we go with what we find. In addition, it would be awesome if addon developers can start creating forum threads for their respective addons, in order to get feedback, announce bugs, etc.  I think this will help make a centralized place of info and feedback.  Useful if you can also use version numbers in your forum postings, too.
>> anyway, we think getting rid of addons.openframeworks.cc <http://addons.openframeworks.cc> will help alot.  Please jump in with any ideas you have -- and also, if you want to help list stuff on the pirate pad (other addons you know about, etc) please go for it!   It's just a rough list of what they found in a day. take care, zach ------------------------------------------------------------------------
>> _______________________________________________
>> of-dev mailing list
>> of-dev at dev.openframeworks.cc
>> http://dev.openframeworks.cc/listinfo.cgi/of-dev-openframeworks.cc
> _______________________________________________
> of-dev mailing list
> of-dev at dev.openframeworks.cc
> http://dev.openframeworks.cc/listinfo.cgi/of-dev-openframeworks.cc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://dev.openframeworks.cc/pipermail/of-dev-openframeworks.cc/attachments/20100713/3f73ad4a/attachment-0003.htm>


More information about the of-dev mailing list