Mogre 1.7.4 Enhancements

BrainScan

13-02-2014 07:11:59

In preparation to create a new development branch for my work on Mogre 1.8, I have started to commit various 1.7.4 enhancements to my BitBucket fork. It can be found here: https://bitbucket.org/BrainScan/mogre

Primarily, doing this helps me get familiar with Mercurial, but also it will bring the 1.7.4 code base closer to my starting point for 1.8.1. I'm not positive what the best way to do pull requests is since I've got a fairly diverse set of little enhancements. Any advice on that?

BrainScan

14-02-2014 04:48:17

I believe I have successfully merged all of my 1.7.4 enhancements into my BitBucket fork: https://bitbucket.org/BrainScan/mogre

These enhancements allowed me to create a basic working Deferred Shading renderer in Mogre 1.7.4. They also serve as the baseline for my work on 1.8.1. I would greatly appreciate if someone could test out the changes and make sure I didn't mess something up when merging them with mercurial. Also, if someone could suggest the best way to submit a pull request to the main repository that would be awesome.

Summary of changes:
  1. Wrapped CustomCompositionPass[/*:m]
  2. Wrapped CompositorManager.RegisterCustomCompositionPass and CompositorManager.GetCustomCompositionPass[/*:m]
  3. Wrapped RenderSystemOperation[/*:m]
  4. Wrapped SceneManager._pauseRendering and SceneManager._resumeRendering[/*:m]
  5. Updated RenderWindow.setDeactivateOnFocusChange to become the setter of IsDeactivatedOnFocusChange[/*:m]
  6. Added a generic WriteData method to HardwareBuffer to allow usage without needing pointers and unsafe code[/*:m]
  7. Fixed the error in ManualObject that prevented various functions from being wrapped[/*:m]
  8. Fix Camera.WorldSpaceCorners to bring back a managed array instead of a pointer[/*:m]
  9. Prevented occasional crashes related to the native environment trying to dispose an object twice[/*:m]
  10. Ported additional functionality in the following classes:
    1. AxisAlignedBox[/*:m]
    2. ColourValue[/*:m]
    3. Math[/*:m]
    4. Matrix3[/*:m]
    5. Matrix4[/*:m]
    6. Plane[/*:m]
    7. Quaternion[/*:m]
    8. Vector2[/*:m]
    9. Vector3[/*:m]
    10. Vector4[/*:m][/list:u][/*:m][/list:u]

se5a

14-02-2014 06:38:22

Added a generic WriteData method to HardwareBuffer to allow usage without needing pointers and unsafe code
does that mean we can do billboards without pointers/unsafe code?

I'll have a go at trying to build this over the weekend.

BrainScan

14-02-2014 06:56:59

I'm not sure about billboards. I use the the new WriteData method to write to directly to a VertexBuffer. It that what you're doing? Which method(s) are requiring unsafe code?

se5a

14-02-2014 07:19:36

iirc anything involving setting texture... locations? manualy required a ptr. I'll have to dig around to find out exactly.

Edit: bit distracted at the moment, but some real quick examples:

http://www.ogre3d.org/tikiwiki/tiki-ind ... ogre.Image

http://www.ogre3d.org/tikiwiki/tiki-ind ... Billboards

se5a

15-02-2014 00:20:07

So I've pointed MogreBuilder at this repository, it's checking everythign out now. will see what happens....

Ok Mogre builder apears to have built it without any problems. I'll copy my mogeroids project and throw it in that and see how it runs later.

se5a

15-02-2014 04:19:24

yeah dropping the built dlls in my project and building and running it worked fine. except for the MOIS being .net4.5 problem.
havin't looked at textures/billboarding yet.

se5a

15-02-2014 20:56:31

Took another look at the billboards.
One key place is BillboardSet.SetTextureCoords needs a FloatRect*
see this thread: viewtopic.php?f=8&t=8987

the other key place is converting an System.Drawing.image to an Mogre.Image as I already linked above: http://www.ogre3d.org/tikiwiki/tiki-ind ... ogre.Image

(the other link with movable text is doing the same thing)

BrainScan

15-02-2014 21:47:21

Ok Mogre builder apears to have built it without any problems. I'll copy my mogeroids project and throw it in that and see how it runs later.
Excellent news! I was worried that MogreBuilder might have to be updated to make it work.

yeah dropping the built dlls in my project and building and running it worked fine.
Could you verify that the new functions are actually available? For example, SceneManager._pauseRendering()?

Took another look at the billboards.
One key place is BillboardSet.SetTextureCoords needs a FloatRect*
see this thread: viewtopic.php?f=8&t=8987

I just pushed a commit that should fix this one. It compiles fine, but I don't have the means to test it right now. Can you let me know if it works?

the other key place is converting an System.Drawing.image to an Mogre.Image as I already linked above: http://www.ogre3d.org/tikiwiki/tiki-ind ... ogre.Image
This one's a little trickier. There's a lot of possible way to go about it. Do you by any chance have a more complete snippet of code of how you're using it in your project?

Thanks for the help so far! We'll get Mogre whipped into shape in no time.

se5a

16-02-2014 00:13:37


Could you verify that the new functions are actually available? For example, SceneManager._pauseRendering()?

I threw it in my project to hit that when I fired a bullet, and got:
"System.Runtime.InteropServices.SEHException' occurred in Mogre.dll
Additional information: External component has thrown an exception."

the ogre.log says:

12:55:09: OGRE EXCEPTION(3:RenderingAPIException): Error ending frame in D3D9RenderSystem::_endFrame at F:\Users\se5a\Documents\Projects-Code\MogreBuild2\Main\OgreSrc\ogre\RenderSystems\Direct3D9\src\OgreD3D9RenderSystem.cpp (line 2863)

if you want an simple testbed, you can take a look at this project I've been messing with: https://bitbucket.org/se5a/mogreoids it should build and run as is at this point in time, it has the new mogre dlls from building just before (not the fix you've just done to the billboardset yet)

RE: the billboards: TBH I've not yet got code that's actualy using it, I've been putting it off due to not being 100% sure about how I'm goign to do it, and billboard examples for mogre are a little thin, I might end up throwing http://www.ogre3d.org/tikiwiki/tiki-ind ... eManager2d in a project to play around.
For the above project I was considering using billboards for a beam weapon effect. will likely be cheaper than a particle system.

for translating an drawing.image to an ogre.image was another project I was messing with where we already had drawing.images loaded and were looking at maybe using that on a billboard in an mogre window. it didn't get that far though, I got distracted by stuff I already knew how to do.

BrainScan

16-02-2014 00:46:13


Could you verify that the new functions are actually available? For example, SceneManager._pauseRendering()?

I threw it in my project to hit that when I fired a bullet, and got:
"System.Runtime.InteropServices.SEHException' occurred in Mogre.dll
Additional information: External component has thrown an exception."

An exception is to be expected. I simply wanted to make sure that the new stuff was ending up in the build. That particular function is a "use only if you know what you're doing" kind of function and only works at very specific points in the render pipeline. I'm using it in my project to implement Deferred Shading, so I know it works when called at the appropriate time.


RE: the billboards: TBH I've not yet got code that's actualy using it, I've been putting it off due to not being 100% sure about how I'm goign to do it, and billboard examples for mogre are a little thin, I might end up throwing http://www.ogre3d.org/tikiwiki/tiki-ind ... eManager2d in a project to play around.

That example would definitely be a place where the new WriteData function could be used to avoid the unsafe code.

se5a

16-02-2014 09:10:27

I confess I don't understand well enough about how it works to convert it, a wild guess it's going to be something along the lines of:


while (node != null)
{
currSpr = node.Value;
thisChunk.Alpha = currSpr.Alpha;
thisChunk.TexHandle = currSpr.TexHandle;

for (int i = 0; i < 6; i++)
{
hardwareBuffer.WriteData<Vertex>(currSpr.Pos[i], currSpr.UV[i], ????, true);
//buffer++ = new Vertex(
// currSpr.Pos[i],
// currSpr.UV[i]);
}...



in the private static void Render() method/function

BrainScan

16-02-2014 17:45:39

It would go something like this:
// write quads to the hardware buffer, and remember chunks
//unsafe
//{
//Vertex* buffer = (Vertex*)hardwareBuffer.Lock(HardwareBuffer.LockOptions.HBL_DISCARD);
Vertex[] buffer = new Vertex[sprites.Count * 6];
int index = 0;

LinkedListNode<Sprite> node = sprites.First;
Sprite currSpr;

while (node != null)
{
currSpr = node.Value;
thisChunk.Alpha = currSpr.Alpha;
thisChunk.TexHandle = currSpr.TexHandle;

for (int i = 0; i < 6; i++)
{
buffer[index++] = new Vertex(
currSpr.Pos,
currSpr.UV);
}

thisChunk.VertexCount += 6;

node = node.Next;

if (node == null || thisChunk.TexHandle != node.Value.TexHandle || thisChunk.Alpha != node.Value.Alpha)
{
chunks.Add(thisChunk);
thisChunk.VertexCount = 0;
}
}
//}

hardwareBuffer.WriteData(0, buffer.Length, buffer, true);
//hardwareBuffer.Unlock();

se5a

16-02-2014 18:47:39

Ah. that makes more sense than my guess.
will test that out tonight when I come home from work.

Beauty

17-02-2014 20:03:39

First of all: Thank you very much for your effort!!

Your changes are looking sweet.
(Especially this: "Prevented occasional crashes related to the native environment trying to dispose an object twice")

I have started to commit various 1.7.4 enhancements to my BitBucket fork
Good idea.

I'm not positive what the best way to do pull requests is since I've got a fairly diverse set of little enhancements.
I'm not shure if it's the best way, but I would say that you do a commit to your fork for each little enhancement. Then it's good for others (and yourself) to understand the purpose of each code modification.
I don't mean each line of code, I mean the changes for one feature / enhancement.

By use of Mercurial and BitBucket it should be easy to push changes from your repository to the main repository. It's also possible to just push a subset of changes.

I believe I have successfully merged all of my 1.7.4 enhancements into my BitBucket fork
Oh, you already did it. Good boy.

I would greatly appreciate if someone could test out the changes
When I find some time, I want to build Mogre by your code and use the binaries in my Mogre project.
It's no complete check, but if there are problems, I can tell you details.

the best way to submit a pull request to the main repository
One easy way would be to change the URL in TortoiseHG form your repository to the main repository.
You wrote, you are not shure about the usage of Mercurial. So I like that you created a fork for learning by doing.
BitBucket offers nice possibilities to push changes to an other repository (e.g. our main), but currently I don't know how to do that. I think there is a description on the website.
When you are shure that you are confirm with Mercurial, I would like to give you write access to the Mogre repository.

Fixed the error in ManualObject that prevented various functions from being wrapped
I used ManualObject much, but I never saw missing functions. Can you tell me an example?

Ported additional functionality in the following classes
In January 2012 I added important changes to the managed classes Vector3, Matrix3 and Quaternion.
Please check, if these are still inside of your ones.
(The answer should be yes, if you modified the code of the main repository after January 2012.)

I simply wanted to make sure that the new stuff was ending up in the build.
You are still afraid of trying out the MogreBuilder, although the usage is so easy.


Branches in Mogre repository

I checked the commits for the last year and saw an important point:
There were many many commits, but they were applied only to the default branch.
The TerrainAndPaing branch wasn't changed after January 2012.
Mercurial offers an option to merge commits from one branch to an other one. Unfortunately I don't know how.
I think it's important to do this (and before pushing the changes to an internet repository there should be a quick test if the code can be build and the binary files run).

An other option would be to merge the commits of the TerrainAndPaging branch to the default branch.
But I can't say if this is good, because the modifications for wrapping the paging/terrain components are incomplete and more like a quick and dirty style (as I read from the previous maintainer mstoyke).
Maybe this could make Mogre instable? Maybe it doesn't care as long as some body doesn't use the functionality of the components? I don't know.

What do you think how to handle this?


Additionally there is a branch names Mogre17.
It's only a short branch of 2010 and the changes were merged to the default branch.
I think it would be a good idea to close that branch, because it can confuse people.

BrainScan

17-02-2014 23:09:51

One easy way would be to change the URL in TortoiseHG form your repository to the main repository.
You wrote, you are not shure about the usage of Mercurial. So I like that you created a fork for learning by doing.
BitBucket offers nice possibilities to push changes to an other repository (e.g. our main), but currently I don't know how to do that. I think there is a description on the website.
When you are shure that you are confirm with Mercurial, I would like to give you write access to the Mogre repository.

I'm new to mercurial but I have used source control extensively in the past. I have used Git in the past and my company currently uses Plastic. So, I understand all the basic concepts of branching, merging, etc. Just not the mercurial specific way of doing things.

I used ManualObject much, but I never saw missing functions. Can you tell me an example?
There was a few ampersands (&) in the doxygen comments in ManualObject that caused the doxygen (cpp2java) step to fail on it. So someone had created a fixed version of the doxygen output for ManualObject located in the fixedDoxygen folder. That meant that the ManualObject wrapping was stuck at the point in time the fixed version was created. If I remember correctly, the function that I was missing was the Tangent function so I could do proper normal mapping. To fix it, I updated the CLRObject patch to fix the ampersands that caused problems in doxygen and the wrapper does the rest.

In January 2012 I added important changes to the managed classes Vector3, Matrix3 and Quaternion.
Please check, if these are still inside of your ones.

Yes. I forked off of the tip of the default branch, which currently includes all commits in the official repository.

You are still afraid of trying out the MogreBuilder, although the usage is so easy.
My company uses a highly customized build process specific to our projects so MogreBuilder is of no direct use for us. I would rather be spending my time improving Mogre than trying to make MogreBuilder work for us. I'm sure its great for new users of Mogre. Hopefully someone can keep improving on it.

Branches in Mogre repository [...]
I wasn't sure what the branching guidelines were for Mogre, so I just followed suit pushing everything to the default branch. Many projects keep a branch for each major version so that crucial bug fixes and such can still be applied to older versions when the project has moved on to newer versions. For example, in the Ogre repositories they have the following branches (v1-7, v1-8, v1-9, etc) In this case, the default branch (sometimes called trunk, that may just be Git terminology) usually has all the latest changes but may be slightly unstable. Changes can then be merged to whatever branch is appropriate. There are many different strategies though. I'm not sure what works best in Mercurial or what would be best for Mogre.

se5a

18-02-2014 22:59:13

Yup. I can report that http://www.ogre3d.org/tikiwiki/tiki-ind ... eManager2d now works without unsafe code. (at least, as far as a quck check to see that the texture renders on the screen under OpenGL and DX9 go anyway)
Beauty, let me know when you've got these changes pulled from Brainscan and I'll look at tweeking this page on the wiki.

quckly realised that this is not going to do anything for me in my current project though, since it's all screen dimensions. might look at an adaption of MovableText, since that apears to be attached to a node, and so is probibly closest to what I'm trying to do. ( a 2d sprite in 3d space) http://www.ogre3d.org/tikiwiki/tiki-ind ... Billboards

BrainScan

20-02-2014 21:49:32

Good to hear it works at least.

Do you actually need to load image data from System.Drawing.Image instead of through the Ogre resource system? If you can use files for your images, BillboardSet may do the job for you.

se5a

21-02-2014 06:34:55

yeah probibly, I just need to sit down and actualy get a billboard so I've got some idea of how it works. or something.

se5a

26-02-2014 01:39:12

Ah, I remember why I was wanting to use system.drawing now.
the art that we've currently got is a bunch of 32x32 images in one large .bmp file.
though I've been tossing up weather to use that art for a while now anyway.

BrainScan

26-02-2014 03:10:57

In that case, the BilboardSet is perfect! Check out the SetTextureStacksAndSlices(). You tell the BillboardSet how many images are across and down and then it indexes them for you. Then for each Billboard you can set its TexcoordIndex to get it to use the right section of the larger texture. This also makes it more efficient for rendering since the texture doesn't have to be swapped as often.

se5a

26-02-2014 03:53:58

Ohh I'll have to mess with that then.
might be usefull/more efficent for bullet effects instead of the current little 3d bullet models I'm using.