OgreAddons Resurrect

[insider]

Looks like we have our own private Ogre Summer of Code (OSOC).
Why should Google have all the fun

Thanks a lot jacmoe for all the effort

[Zonder]

I was thinking the projects probably should be branched for the version of ogre they support so default can be bleeding edge version of ogre. But older versions are still available.

[Transporter]

I was thinking the projects probably should be branched for the version of ogre they support so default can be bleeding edge version of ogre. But older versions are still available.

No, it is better to create CMake files for all addons and check the Ogre version in that scripts.

[Zonder]

I was thinking the projects probably should be branched for the version of ogre they support so default can be bleeding edge version of ogre. But older versions are still available.

No, it is better to create CMake files for all addons and check the Ogre version in that scripts.

Not sure I follow what you mean?

I was referring to the fact that some add ons might support ogre 1.4 currently then some one fixes it to work with ogre 1.10. If they are branched as they stand with the version they currently work with people can quickly get the version they need / see it will need updating to support the version of ogre they need (we have the same problem with wiki articles for example)

Some one also might find an add on for version 1.10 and need to back port it to 1.7 they could then create a branch for that version with the necessary changes.

You can of course do this with labelling but it was the back porting part I was thinking branches are better since you wouldn't want the backport in the main branch

I suppose I am so used to packages these days and been able to match versions to what I need

[jacmoe]

I think it probably would be a good idea to start branching once the projects is being ported to Ogre 2.x.
For example, when the Ogitor used addons - I don't know how many of them actually survive the port - gets ported, then we will probably create a branch 'ogre1' or something before porting. 'default' will most probably be for current Ogre, since Ogitor can't depend on using bleeding edge.

[frostbyte]

I was thinking the projects probably should be branched for the version of ogre they support so default can be bleeding edge version of ogre. But older versions are still available.

was thinking the same thing...doing branching according to ogre versions
this way people can fork directly from the compatible ogre branch they want to "work on" or convert to...
but it can be a problem if someone mistakes this new branch to be working and try to use it ...
wish there was some way to inform on branch status( WIP/PORTED ) but i dont see any beside maybe creating branches with names like WIP1.10, WIP2.0 etc

[Zonder]

This is what I am getting at the branches should match an ogre version so people can easily identify that it's for ogre x.xx I was just meaning before people start working on these branch now to the version of ogre they support and default can be the main dev branch for v2.

I just think it needs to be as easy as possible.

[frostbyte]

at current situation you dont know which ogre version the addOn runs on but at least you know that you dont know...
if we start opening new branches people might mistake them to be available ports...
i understand what you are saying and totaly agree but still there is this little big problem...
so only solution i see is naming them something like "initial_port_to_2.x-WIP" and renaming/merging them to "2.x" after they get fully converted

as jacmoe mentioned before, feel free to join the ogreAddons team and do your thing

[Zonder]

Yeah true I suppose some of these we won't know what version. At the moment I am working on something for version 2 so my free time is limited but once I finish I might tackle some stuff in here.

Maybe this repository should be the place for v2 resources? and forget about the older versions? so when something gets working in v2 branch it until then it's in an unknown state

[frostbyte]

Maybe this repository should be the place for v2 resources? and forget about the older versions?

first reason it was created is to gather and maintain usful code in one place instead of letting it rot somewhere on the web...
but it has other uses as well...read first post...porting code to 2.x is for sure a very important goal but not the only one...
i think its too soon to forget about 1.x but atleast now if users port an Addon to 2.x they knows where to publish it...

some reallife scenerios:
hydrax for example existed on 3 differnet unrelated repos...
dotScene had many half baked versions instead of concentrating effort on one good version...
the amazing scriptSerializer was hiding from public eyes...
the "how come this isn't part of ogre?" animicon was rotting anonymously on github...
cool field-of-deapth-demo i found on youtube searched for the author and got a zip file from his personal website...
and so on and on each Addon and his story...
we'll be glad to have you onboard...and as always...no strings attached

[insider]

No love for Berkelium
http://www.ogre3d.org/tikiwiki/tiki-ind ... =Berkelium

Edit:

Oh I see we have ogreHTML on the main page, that sounds great

[frostbyte]

insider, if you find some code that "dont get much love" just import it to your own bitbucket repo and send a transfer request...
ogreHtml has more functionality than the snipplet, thats why i've decided to put it there, but the snipplet is easier to understand so i guess it's still useful...

[Crashy]

I've just seen that topic. As many other people here, I've ported my own fork of PagedGeometry to Ogre 2.0, plus a lot of custom modifications and hacks we did for BOMB...

Anyway, if somebody wants to check the impostor generation code using the new Compositor system, it works. Not very clean code, but as it "just" work...that's fine for now

Here a dirty archive
http://crashy.cartman.free.fr/ogre3d/PagedGeometry2.7z