Ogre Forums

c6burns wrote:Oh wait I just remembered ... it's not that statically linking an LGPL lib means the combined work must be LGPL. It's that you must provide everything necessary for end users to be able to re-link the application. So any license would be fine, but closed commercial source cannot statically link an LGPL library. This is where my problem with the LGPL lies, in terms of it being applied to code I want to use in my application's runtime. I might release all of my work under MIT in the end, but I would prefer not to be shoehorned into that just because I had to static link some tiny LGPL library for a mobile platform.

Not that I forsee Ogitor causing this to be a problem, just venting about LGPL in general. I have faith in the sensibility of Ogitor's creators

Middle-ware should never, ever be licensed under the LGPL IMO. MIT or Zlib all the way! But we need to decide that as a team, when it's ready to be (widely) used
What I really meant was that LGPL for Ogitor means that we can include third-party code directly into our code base without multiple license issues. No biggie, though.

About re-using and licensing...,
i can use the OFS library?, seems very good for me, i need to modify it a bit (replacing SpinWait class with Tbb or POCO mutexes) to meet my necessities as well compression. I don't liked PhysFS for a long time, i tried StormLib but involves too much specific for Blizzard games...

Also some improvements can made: using HashMaps than ordinary std::maps to get a bit more of performance...

c6burns wrote:Oh wait I just remembered ... it's not that statically linking an LGPL lib means the combined work must be LGPL. It's that you must provide everything necessary for end users to be able to re-link the application. So any license would be fine, but closed commercial source cannot statically link an LGPL library. This is where my problem with the LGPL lies, in terms of it being applied to code I want to use in my application's runtime. I might release all of my work under MIT in the end, but I would prefer not to be shoehorned into that just because I had to static link some tiny LGPL library for a mobile platform.

Not that I forsee Ogitor causing this to be a problem, just venting about LGPL in general. I have faith in the sensibility of Ogitor's creators

The basic idea of LGPL is that the user is able to modify or replace an LGPL component of a product. If it's an LGPL library, they need to be able to replace the library with a customised or updated version. If the library is dynamically linked, that's easy (at least in theory), just replace the dll. For static linking, an LGL lib can be replaced if you provide all obj and lib files used during linking. No source code is needed (although it's easier than giving out all the temp compiler files).

hydexon wrote:About re-using and licensing...,
i can use the OFS library?, seems very good for me, i need to modify it a bit (replacing SpinWait class with Tbb or POCO mutexes) to meet my necessities as well compression. I don't liked PhysFS for a long time, i tried StormLib but involves too much specific for Blizzard games...

Also some improvements can made: using HashMaps than ordinary std::maps to get a bit more of performance...

OFS in old Ogitor code is already MIT, you could use it and apply some of the changes/fixes made in new Ogitor code.

EDIT: Nvm, its MIT in new code too...

stealth977 wrote:

hydexon wrote:About re-using and licensing...,
i can use the OFS library?, seems very good for me, i need to modify it a bit (replacing SpinWait class with Tbb or POCO mutexes) to meet my necessities as well compression. I don't liked PhysFS for a long time, i tried StormLib but involves too much specific for Blizzard games...

Also some improvements can made: using HashMaps than ordinary std::maps to get a bit more of performance...

OFS in old Ogitor code is already MIT, you could use it and apply some of the changes/fixes made in new Ogitor code.

EDIT: Nvm, its MIT in new code too...

Thanks you!, althrough, the compression is a thing which is missing, i heard Kojack (or was jacmoe?) modified OFS to compress files with Zlib...

Not me (although my memory does suck at times).

Kojack wrote:Not me (although my memory does suck at times).

Goddamnit, i sniffed the OFS internals and i gonna got a hard time if i try.

In other part just almost finished to port OFS with POCO, replaced Boost::FileSystem with Poco::File & Poco::Path and the SpinWait classes with Poco::Mutex... was pretty straightfoward, i don't know if i should change the standard std::map with Poco::HashMap for a bit more of performance, but i have a goddamn IntelliSense error which can't define the dllimport entity, since removed sync.h and sync.cpp and replaced those classes with Poco::Mutex and ScopedLock...

EDIT: Nevermind about the dllimport entity, i had to define OFS_EXPORT in order to solve the error...
EDIT #2: OFS lib works or behaves like the PhysFS?, which allowed me to "mount" multiple archives, it's because i don't like to have plenty of big files inside in a whole OFS archive...

Someone has the sample files which used to test Ogitor 2.0? i would want to know how the serialization of scenes occurrs...

Is the main development for Ogitor still going to be https://bitbucket.org/ogitor/ogitor ? I'm wondering about where this OGRE 2.0 branch is currently being developed?

Development was happening there : https://bitbucket.org/ogitor/ogitor-v2/commits/all
As you can see, it hasn't seen any progress since more than 2 years. I suppose Ismail has moved on.

Hi,

Ogitor started as an all purpose scene editor, but in time I realized that it is harder for people to use if they can not directly develop something with it. Also being "all purpose" made it much slower...

So, I decided to re-make it, to include its own engine (could be used with/or without) also was planning to use OGRE 2.0, but this time, the enormous amount of work that needs to be done just consumed me, with the edition of various multi-threading related design problems just caused me to give up...

So, the development of it stopped. Given that I am too busy with real-life responsibilities, I probably will never have enough time to work on a project like Ogitor...

stealth977 wrote:Hi,

Ogitor started as an all purpose scene editor, but in time I realized that it is harder for people to use if they can not directly develop something with it. Also being "all purpose" made it much slower...

So, I decided to re-make it, to include its own engine (could be used with/or without) also was planning to use OGRE 2.0, but this time, the enormous amount of work that needs to be done just consumed me, with the edition of various multi-threading related design problems just caused me to give up...

So, the development of it stopped. Given that I am too busy with real-life responsibilities, I probably will never have enough time to work on a project like Ogitor...

The point is you tried and realised wisely it was to much to take on.

I think now with the work spookyboo has done with the Magus GUI Wizard should help people get a head start on their own editors as it is just focusing on common concepts needed so you can customise the final result and the HLMS editor is showing it off nicely.