Ogre 1.7.5 (Backporting 1.8.1 fixes)
-
- Halfling
- Posts: 51
- Joined: Tue Jun 05, 2012 4:33 pm
- x 1
Ogre 1.7.5 (Backporting 1.8.1 fixes)
Dear readers,
the Mogre community is stuck on Ogre 1.7.4 for a while now and it seems more than one person failed porting it to 1.8.1 so far.
I was interested in the changes that have been made between 1.7.4 and 1.8.1 and so I created a diff package:
This contains a .diff file (sometimes emtpy) for each file that exists in 1.7.4 AND 1.8.1 - same directory structure.
https://googledrive.com/host/0B-6rsj6uH ... atches.zip
I started looking for simple fixes/changes.
This don't include application design or other major changes.
The attached file to this thread is a good example for such local "fix" which I made based on the patch for the specific file from the package above.
It contains the additional "if-condition", but no other changes.
What I'd like to know now:
Is there any interest in releasing a bugfixed 1.7.5?
I could create a bitbucket fork of 1.7.4 for that approach.
Ortherwise I just keep this within our small Mogre community..
the Mogre community is stuck on Ogre 1.7.4 for a while now and it seems more than one person failed porting it to 1.8.1 so far.
I was interested in the changes that have been made between 1.7.4 and 1.8.1 and so I created a diff package:
This contains a .diff file (sometimes emtpy) for each file that exists in 1.7.4 AND 1.8.1 - same directory structure.
https://googledrive.com/host/0B-6rsj6uH ... atches.zip
I started looking for simple fixes/changes.
This don't include application design or other major changes.
The attached file to this thread is a good example for such local "fix" which I made based on the patch for the specific file from the package above.
It contains the additional "if-condition", but no other changes.
What I'd like to know now:
Is there any interest in releasing a bugfixed 1.7.5?
I could create a bitbucket fork of 1.7.4 for that approach.
Ortherwise I just keep this within our small Mogre community..
- Attachments
-
- OgreOctreeNode.cpp.patch
- Ogre 1.7.4 -> 1.8.1 for OgreOctreeNode.cpp
- (1.01 KiB) Downloaded 113 times
- spacegaier
- OGRE Team Member
- Posts: 4304
- Joined: Mon Feb 04, 2008 2:02 pm
- Location: Germany
- x 135
- Contact:
Re: Ogre 1.7.5 (Backporting 1.8.1 fixes)
Why is porting to 1.8.1 failing (or even for Ogre 1.9 since that will soon be the current version)?
I am not sure if we wan to go through the hassle of releasing a new 1.7.x version.
PS: Could you provide a single diff file with all changes, because if one dev team member has to apply all those many hundreds diff files one after the other, no one will tackle that. A pull request would in fact be the correct way to provide such a potential patch/change.
I am not sure if we wan to go through the hassle of releasing a new 1.7.x version.
PS: Could you provide a single diff file with all changes, because if one dev team member has to apply all those many hundreds diff files one after the other, no one will tackle that. A pull request would in fact be the correct way to provide such a potential patch/change.
Ogre Admin [Admin, Dev, PR, Finance, Wiki, etc.] | BasicOgreFramework | AdvancedOgreFramework
Don't know what to do in your spare time? Help the Ogre wiki grow! Or squash a bug...
Don't know what to do in your spare time? Help the Ogre wiki grow! Or squash a bug...
- Zonder
- Ogre Magi
- Posts: 1168
- Joined: Mon Aug 04, 2008 7:51 pm
- Location: Manchester - England
- x 73
Re: Ogre 1.7.5 (Backporting 1.8.1 fixes)
The porting problem is to do with the wrapping process. No one has had the time to sit down and update the configuration as needed / debug the errors. Updating 1.7.4 with 1.8 changes will just break the wrapping process most likely.
I am hoping to become active on my own projects again soon and updating MOGRE is on my list, if no one else has done it.
I am hoping to become active on my own projects again soon and updating MOGRE is on my list, if no one else has done it.
There are 10 types of people in the world: Those who understand binary, and those who don't...
- Kojack
- OGRE Moderator
- Posts: 7157
- Joined: Sun Jan 25, 2004 7:35 am
- Location: Brisbane, Australia
- x 534
Re: Ogre 1.7.5 (Backporting 1.8.1 fixes)
Unfortunately mogre seems to be dead, which is a shame. There's even at least 1 commercial game on Steam that uses it, so it's a reasonable platform for C# fans.
I tried getting 1.8 working, but got quickly put off.
What would be cool is if Ogre supported Mogre more directly. For those that don't know, Mogre is built by patching ogre's source (adding a macro on every class definition), building it in C++/CLI (the non standard C++ version for .Net), then wrapping it with properties and changed function names (like a Position property instead of setPosition and getPosition, everything using pascal case instead of camel case, etc) by running it through a custom tool. Doing that to all of ogre is painful. Just getting the existing diffs to apply is hard.
If some of the changes needed in the diffs (mainly class macros) could be added to normal ogre, it would make porting easier.
For example, the Node class in ogre looks like:
while in mogre it needs to look like
I tried getting 1.8 working, but got quickly put off.
What would be cool is if Ogre supported Mogre more directly. For those that don't know, Mogre is built by patching ogre's source (adding a macro on every class definition), building it in C++/CLI (the non standard C++ version for .Net), then wrapping it with properties and changed function names (like a Position property instead of setPosition and getPosition, everything using pascal case instead of camel case, etc) by running it through a custom tool. Doing that to all of ogre is painful. Just getting the existing diffs to apply is hard.
If some of the changes needed in the diffs (mainly class macros) could be added to normal ogre, it would make porting easier.
For example, the Node class in ogre looks like:
Code: Select all
class _OgreExport Node : public NodeAlloc
{
public:
Code: Select all
class _OgreExport Node : public NodeAlloc, public CLRObject
{
public:
DECLARE_INIT_CLROBJECT_METHOD_OVERRIDE(Node);
- Zonder
- Ogre Magi
- Posts: 1168
- Joined: Mon Aug 04, 2008 7:51 pm
- Location: Manchester - England
- x 73
Re: Ogre 1.7.5 (Backporting 1.8.1 fixes)
Personally I don't think MOGRE needed the pascal casing and properties adding. Using the API as is would be better so documentation is the same / samples are the same etc.
There are 10 types of people in the world: Those who understand binary, and those who don't...
- Kojack
- OGRE Moderator
- Posts: 7157
- Joined: Sun Jan 25, 2004 7:35 am
- Location: Brisbane, Australia
- x 534
Re: Ogre 1.7.5 (Backporting 1.8.1 fixes)
I think the properties worked pretty well (made ogre feel more like a native c# app) but it does make the interface inconsistent between mogre and ogre.
There were also some problems where Mogre reimplemented some code (for efficiency I guess) but didn't include fixes ogre made. For example, There are parts of mogre that use the .net acos and asin, which can cause NANs, while ogre has safer versions in Ogre::Math that avoid NANs.
There were also some problems where Mogre reimplemented some code (for efficiency I guess) but didn't include fixes ogre made. For example, There are parts of mogre that use the .net acos and asin, which can cause NANs, while ogre has safer versions in Ogre::Math that avoid NANs.
-
- Halfling
- Posts: 51
- Joined: Tue Jun 05, 2012 4:33 pm
- x 1
Re: Ogre 1.7.5 (Backporting 1.8.1 fixes)
@spacegaier
Do not apply this on any sources, it won't work.
I used this to easily (and offline) start to check for differences between the versions, because somehow the bitbucket history did not seem very usable to me.
What I suggested is to use certain bugfixes from which you can get from these patches and bundle them into an Ogre 1.7.5 version.
The patch file I attached is an example for such a bugfix.
I think you misunderstood. The giant patch-pack which I linked for download is nothing but an autogenerated set of diffs.PS: Could you provide a single diff file with all changes, because if one dev team member has to apply all those many hundreds diff files one after the other, no one will tackle that. A pull request would in fact be the correct way to provide such a potential patch/change.
Do not apply this on any sources, it won't work.
I used this to easily (and offline) start to check for differences between the versions, because somehow the bitbucket history did not seem very usable to me.
What I suggested is to use certain bugfixes from which you can get from these patches and bundle them into an Ogre 1.7.5 version.
The patch file I attached is an example for such a bugfix.
-
- Halfling
- Posts: 51
- Joined: Tue Jun 05, 2012 4:33 pm
- x 1
Re: Ogre 1.7.5 (Backporting 1.8.1 fixes)
@Kojack
Mogre is still my No. 1
I was having these issues with angle calculations between vectors like this 1)cosphi=v3*unitx 2)phi=acos(..)
However I never ran into it again when normalizing the v3 before, but I agree that acos can give you NaN.
I think the .NET math was choosen because of performance to not wrap the most simple classes (but it's double based as far as I know...)
@Zonder
@Zonder
I don't think Mogre is dead, there are not that many choices if you look for an highly customizable and powerful C# engine.Unfortunately mogre seems to be dead, which is a shame. There's even at least 1 commercial game on Steam that uses it, so it's a reasonable platform for C# fans.
Mogre is still my No. 1
Hmm. I can remember having this problem too, because I basically use Mogre just for rendering and run a lot of math on my own.For example, There are parts of mogre that use the .net acos and asin, which can cause NANs
I was having these issues with angle calculations between vectors like this 1)cosphi=v3*unitx 2)phi=acos(..)
However I never ran into it again when normalizing the v3 before, but I agree that acos can give you NaN.
I think the .NET math was choosen because of performance to not wrap the most simple classes (but it's double based as far as I know...)
@Zonder
Would love to see more improvements happening to Mogre.I am hoping to become active on my own projects again soon and updating MOGRE is on my list, if no one else has done it.
@Zonder
Agree. If it's done automatically -OK. But I would not invest a single second in transforming two getXY setXY methods into a property.Personally I don't think MOGRE needed the pascal casing and properties adding. Using the API as is would be better so documentation is the same / samples are the same etc.
- Kojack
- OGRE Moderator
- Posts: 7157
- Joined: Sun Jan 25, 2004 7:35 am
- Location: Brisbane, Australia
- x 534
Re: Ogre 1.7.5 (Backporting 1.8.1 fixes)
True. I should have said maintenance of Mogre is dead, since ogre 1.8 came out over a year ago, 1.8RC1 2 years ago, but Mogre is still at 1.7.cyberjunk wrote:@KojackI don't think Mogre is dead, there are not that many choices if you look for an highly customizable and powerful C# engine.Unfortunately mogre seems to be dead, which is a shame. There's even at least 1 commercial game on Steam that uses it, so it's a reasonable platform for C# fans.
Mogre is still my No. 1
- Zonder
- Ogre Magi
- Posts: 1168
- Joined: Mon Aug 04, 2008 7:51 pm
- Location: Manchester - England
- x 73
Re: Ogre 1.7.5 (Backporting 1.8.1 fixes)
Mogre not moving is also due to people not necessarily needing new features. But I will be needing the volume component in my editor so I need it. My time scales are when I get round to it though
Also means I will be skipping 1.8
Also means I will be skipping 1.8
There are 10 types of people in the world: Those who understand binary, and those who don't...
- Kojack
- OGRE Moderator
- Posts: 7157
- Joined: Sun Jan 25, 2004 7:35 am
- Location: Brisbane, Australia
- x 534
Re: Ogre 1.7.5 (Backporting 1.8.1 fixes)
Not being able to load meshes exported for 1.8 or above is a rather annoying feature of mogre that my students ran into recently. They were using ogre 1.8 for their game projects, but making a level editor tool in mogre (for a different subject that uses c#). Ogre 1.8 treats tangents in meshes in a different way. You can upgrade meshes, but not downgrade.
-
- Halfling
- Posts: 51
- Joined: Tue Jun 05, 2012 4:33 pm
- x 1
Re: Ogre 1.7.5 (Backporting 1.8.1 fixes)
Agree, I also don't necessarily need "new features" from 1.8.1 or later.Mogre not moving is also due to people not necessarily needing new features.
However whenever people run into "issues" with the 1.7.4, they might come to the situation asking themself:
Hey is this may be fixed in a later version?
- BrainScan
- Gnoblar
- Posts: 1
- Joined: Fri Feb 14, 2014 6:50 am
Re: Ogre 1.7.5 (Backporting 1.8.1 fixes)
I more or less ran into the exact problem being described here. I was having some problems with compositors in Mogre 1.7.4. First, I attempted to backport some fixes but that was a mess. So, I took it upon myself to update Mogre to 1.8.1. Long story short, I now have a working version of Mogre 1.8.1! You can check out the details over in the Mogre forum: http://www.ogre3d.org/addonforums/viewt ... =8&t=30176
Hopefully, this will help jumpstart the Mogre community a bit!
Hopefully, this will help jumpstart the Mogre community a bit!