[Bloody Mess] Important: Code Repository

Hello All,

I've been spending the last month working with NxOgre. NxOgre is a powerful wrapper for PhysX, but many times I've found myself very frustrated with its use! Documentation is minimal, and there are very few listings of full source to common problems available.

In an effort to help one another, and cut down on the number of questions, especially the simple ones that are asked over and over in the forum to betajaen and others, I'm creating this topic in hopes that the user community of NxOgre will help each other out and solve some of our biggest challenges with NxOgre. As anyone like myself studying NxOgre for the first time as of more recently has found out, there are many versions, and very little documentation on these versions. When reading through forum posts, most of our posts are our own specific questions of how to do stuff related to game development with NxOgre. Most of the time, we post a small slice of our code that we need help with (which 1,000+ other people before us have probably already implemented), then once we get help, we go back to coding, never posting the full solution to the problem. When reading through the forums, there is rarely any full solutions to major problems posted, just small code fragments where people ran into something they couldn't figure out themselves.

It would seem most of what you want to do with NxOgre has already been fully implemented by someone, who is using it right now in their games or other applications, but just hasn't posted their implementation. So the same problems occur over and over again...we continue to waste time trying to code the same solutions ourselves that someone else has already coded, tested, and is using. This is an inefficent waste of talent. Due to the lack of full documentation (which one must expect anyway when a solution of this magnitude only has a single developer, who has his hands full already coding NxOgre and trying to answer all our questions), it can take weeks or months, and many forum posts to work out a full solution of a class or classes to a single physics problem we want implemented in our games. Some of the most common problems we want to use physics for in our games are for adding gravity, collision detection, a character controller, keeping objects from falling through level/terrain geometry, physical interactions with world objects, triggers, vehicles, and ai, all of which should be able to be solved in a generic manner with a simple to use series of well written classes using NxOgre.

After a few weeks of work, a lot of reading, and asking a number of questions in the forums, I've only been able to get some working actors and bodies setup, with gravity and a plane as a floor, and the ability to apply forces. I've been so wrapped up trying to find small undocumented solutions, that I haven't been able to implement a full class yet to solve even one of the aforementioned problems. However, I ask myself...why am I spending weeks implementing something that thousands of others have probably done before me, and which they have probably done it a whole lot better. I also know that when I finish with the implementation, I'm going to have move on and also spend weeks implementing something else that someone else has probably already implemented, and quite possibly better, as they've had time to test it and optimize it.

So here is my proposition: If you've figured out how to do anything major with NxOgre, and implemented a stable and working class, library, set of classes, major functions, etc., that does anything useful that others might want to use with NxOgre, and which would take time for someone else to implement, please share the full source code here! If everyone that has solved a major problem posts their full solutions here, we can figure out who has the best solutions, then all use those in our games/applications. The whole theory behind the licensing of this stuff anyway is that everyone shares, and we work together to make it better! Instead of spending time reinventing the wheel over and over again, we need to work together on making the best classes built with NxOgre better, making them more robust, efficent, and stable. This then helps all of us achieve our goals. If the same piece of code is used and tested by hundreds of programmers, it is far less likely to have problems when you go to release your applications, and also should execute at top speed, as input can be taken from the group as a whole on optimizations. Additionally, this would cut down on the number of questions posted to the forums, and consequently, the number of questions betajaen has to answer -- which in turn will free up a significant amount of time for him to continue his work on NxOgre itself, and also give him optimized classes to use for testing his work, so he doesn't also have to create these.

There are also many things that aren't yet implemented in most versions of NxOgre which others have already solved and added to their games/applications, such as characters, fluids, cloths, physical particles, etc. If you've solved any of these problems, please don't horde your solution! Share it with the community!

I've created two seperate threads for this, one for bleeding, and one for bloody mess, depending upon the version you're using. Please make sure you post your code to the right topic. In the subject line of your posts, please post the version number of bleeding or bloody mess that you used to code your solution with, and what the solution solves.

If this works, and we all work together, this topic should be the most complete place available to quickly find a full solution to all your NxOgre/Physics needs. If you've built working classes/controllers with NxOgre, please post them, or post links to them here!! There are a number of wonderful and intelligent people here, let's work together to make NxOgre the best and only solution people consider for Physics when using Ogre!

Well, first of all: Documentation is constantly increasing. I've already written some tutorials on BloodyMess (more are to come soon) and betajaen is working on his shortguides. I also think that these general code snippets belong in the NxOgre (there is already a respective page), so that everything is toghether in one place and sorted in a sensful manner (one big thread doesn't help at all).

However, thanks for the effort!

PS: Try to make shorter postings. It really scares people when they see such a long text...

I really wish I had more time in the day to work on NxOgre. But in my life right now; I have three major things going on. Unfortunately NxOgre doesn't pay the bills, or gives me education so it's third in my list of priorities. If other people would ease my life a bit, by taking over the documentation, helping out with others, and creating a well tested, and full code repository - I'm willing to give it a shot.

As for developing with NxOgre, although I am unwilling to taking on additional developers as I have a clear map of how I want it to be written. I have a set coding style, and a very high standard and expectations on how the source behaves. However; There may be times if someone produces an exceptional piece of work that has to be in the source code, I will be willing to put it in. A more community based approach would be when I advertise for developers and users of NxOgre to fill in the gaps for me, a good example of this - is the joint system. There are several types joints, which take a good few hours to write in and test. I've already written four in 1.5.4, but if other developers could band together, using the same style of code they could fill in the rest of me.

Documentation has always been poor with NxOgre. Luckily Ageia and NVIDIA have produced some excellent documentation for PhysX, and the way that NxOgre works - much of that still applies. Code snippets have been placed here and there, but with no centralised place, no moderation or quality control. This isn't a big software project, not a big as Ogre, but I would be willing to allow a sub-domain and some proper server space at NxOgre.org for a solution to deal with both of these problems. If somebody can come up with a solution in PHP, Ruby or Python that will help with user written documentation, and user written code that is either managed by an individual or by a community than go for it. I'm hesitant to install big software packages such as MediaWiki, but if tried and tested alternates, that are proven to be secure and efficent. I will install them, and let the NxOgre (and Ogre) community run it.

Anyway, this is me letting go of the reigns a little, if other people are ready to step up. Please do.

Well, first of all: Documentation is constantly increasing. I've already written some tutorials on BloodyMess (more are to come soon) and betajaen is working on his shortguides. I also think that these general code snippets belong in the NxOgre (there is already a respective page), so that everything is toghether in one place and sorted in a sensful manner (one big thread doesn't help at all).

spacegaier, you've done a wonderful job on your bloody mess tutorials. I've read all of your tutorials, both of betajaen's guides, and about 100 pages of the PhysX documentation over the last month, during every bit of downtime I've had. The tutorials and guides are a great start, but they don't show how to use NxOgre in a serious application. There is no documentation or full source code anywhere on how to use NxOgre to do a number of the most common things people want to use it for -- even though I'm sure many people have implemented them already. We need to do a better job of sharing full solutions so there is documentation on it, and you and betajaen don't have to write it all yourselves. The whole community should be able to help out with this. I realize that this isn't the best place for the code, but it's all we really have right now.

Can just anyone post to the code snippets section in the NxOgre wiki page? I've looked through the page, and there are only two pieces of code on it at the moment, even though I read forum posts from people here each day that seem light years ahead with their applications and the problems they are solving, but don't post anymore than a small snippet of their code.

I really wish I had more time in the day to work on NxOgre. But in my life right now; I have three major things going on. Unfortunately NxOgre doesn't pay the bills, or gives me education so it's third in my list of priorities. If other people would ease my life a bit, by taking over the documentation, helping out with others, and creating a well tested, and full code repository - I'm willing to give it a shot..

I totally understand man... As a high school teacher involved in a pile of activities for my students, I'm as short on time as you. Most days I get to work at 7 am, and leave at 7 pm, then fit in some studying of game development for my students in the evenings. I'm just trying to help get things put together in a way that is simple enough for my students to understand, and hopefully also help out the NxOgre community at the same time. The things I've mentioned are things my students really want to learn, as I'm sure many others in the community want to use them as well. If something can't be kept simple, high school kids lose focus and get frustrated. I'm trying to get this stuff put together for them in a way that is somewhat simple, straightforward, and will keep them interested, which seem to be some of the hallmarks of NxOgre, but I can't find any full implementations of the things aforementioned that the kids want to learn, and I don't have the time to write it all myself from scratch. My students don't have degrees in Computer Science. They know some programming, some Ogre, and now some NxOgre, but not enough to be able to read through 1704 topics and 13626 posts to figure out how to do it all themselves. I'm just trying my best to help the kids learn what they are most interested it.

As for developing with NxOgre, although I am unwilling to taking on additional developers as I have a clear map of how I want it to be written. I have a set coding style, and a very high standard and expectations on how the source behaves. However; There may be times if someone produces an exceptional piece of work that has to be in the source code, I will be willing to put it in. A more community based approach would be when I advertise for developers and users of NxOgre to fill in the gaps for me, a good example of this - is the joint system. There are several types joints, which take a good few hours to write in and test. I've already written four in 1.5.4, but if other developers could band together, using the same style of code they could fill in the rest of me.

You're doing a great job betajaen! I see you working your ass off here just about every day, as is evidenced by the Bloody Mess blog and your answers to all of our posts. So I feel bad asking you questions all the time, and want to see more people step up to the plate and contribute so you don't have to put in so much time. After years of development, the community should have most of the main problems solved by now, with robust classes built on top of NxOgre, taking advantage of all implemented features in a simple manner that can be used in a serious application. I'd like to see the community contribute these from their personal projects so we can all share and learn from them. I will gladly contribute any bugs or code any of my students come up with. I'm not advanced enough yet to be able to help with the joint systems; however, when I learn more and have a better understand of the system, I'd be happy to help out in any way I can.

Documentation has always been poor with NxOgre. Luckily Ageia and NVIDIA have produced some excellent documentation for PhysX, and the way that NxOgre works - much of that still applies. Code snippets have been placed here and there, but with no centralised place, no moderation or quality control. This isn't a big software project, not a big as Ogre, but I would be willing to allow a sub-domain and some proper server space at NxOgre.org for a solution to deal with both of these problems. If somebody can come up with a solution in PHP, Ruby or Python that will help with user written documentation, and user written code that is either managed by an individual or by a community than go for it. I'm hesitant to install big software packages such as MediaWiki, but if tried and tested alternates, that are proven to be secure and efficent. I will install them, and let the NxOgre (and Ogre) community run it.

I agree, the nVidia docs are good, especially for learning theory. The training program docs that come with the SDK are also good; however, the code can be very difficult to convert to NxOgre without a solid understanding of how different versions of NxOgre really tick, what classes can be used directly and which should be derived from, etc. And NxOgre consists of a lot of classes, so trying to read through the code to figure this out on our own isn't the most feasible solution for anyone without a heavy coding background and a lot of free time.

Ogre itself also has a similar problem. People are constantly recreating the wheel for such things as camera controller classes, animation blending classes, etc., which people seem to have written great working solutions for, as they mention in some of their posts, but which aren't being shared. I've even sent personal messages to people asking if they would send or post a copy, and they never reply. It's really sad to see so many people taking advantage of open-source without being willing to share some of what they themselves create with it so we can all benefit.

I think the solution you're proposing would probably solve quite a few problems. I haven't installed any of these solutions, anyone in the community able to offer advice on this please??

I think the key is to make it simple enough to obtain source so that in a few days a person can have NxOgre setup and working to solve the main physics problems games face, as listed in nVidia's PhysX_SDK_Integration_Guide.doc.

I'd be happy to help post both code and documentation as I begin to understand how to do more advanced things with the system. As you can tell, I can write and speak English just fine, so docs should be no problem when I know what I'm writing about. Maybe a little too well by the long posts as spacegaier mentioned... oh well, blame American colleges for requiring such long papers all the time! Sorry spacegaier for another one!

The more I think about this idea the more I agree with it.

Two pieces of software catch my eye are Trac and Redmine. I prefer Redmine over the two, due to it using RoR and the ability to use sqlite, rather than a big DBS like mySQL. Either them would be perfect for myself and the community, both have source code tracking built in which is perfect for handling bug requests, release notes, patches and encourages me to set up a repository again. It also has a wiki, which is again perfect for documentation, and handling code snippets. A big bonus is the ability to have forums; something I feel that we've out grown Ogre a little (especially with Bloody Mess) and impose a bit too much on the Ogre server.

I'm even seriously considering just skipping over the sub-domain idea, and just have it directly as the front page.

Okay, I had a little play with Redmine installed on my computer and I love it.

It's exactly what we need and I will install a copy on the NxOgre.org server by the end of the week.

I only had a quick glance at Redmine, but I got to say that this looks extremly nice! Could indeed be a good solution for NxOgre.

Okay, I had a little play with Redmine installed on my computer and I love it.

It's exactly what we need and I will install a copy on the NxOgre.org server by the end of the week.

I just checked out the features as well on their page...looks awesome! For others following the thread...features include:

Multiple projects support
Flexible role based access control
Flexible issue tracking system
Gantt chart and calendar
News, documents & files management
Feeds & email notifications
Per project wiki
Per project forums
Time tracking
Custom fields for issues, time-entries, projects and users
SCM integration (SVN, CVS, Git, Mercurial, Bazaar and Darcs)
Issue creation via email
Multiple LDAP authentication support
User self-registration support
Multilanguage support
Multiple databases support

With the organization it includes, and as long as correct procedures are put together which everyone follows, this should put all of the information in an easy to find, centralized location, so we won't need to hunt through 13,631 posts of many various different topics to quickly find a solution on the same topic that we're working with, which has already been solved, or how to do something that someone has done before, as we can share our code. This way, the documentation and code base help write themselves as the community overcomes problems together. It would seem that once it is setup, the test would be that if all is organized correctly, a question should never need to be asked or answered more than a single time, and it should be simple to find that answer. Members of the community can help keep it organized themselves. Perhaps one idea would be a section for each component of the PhysX SDK, such as actors, joints, etc., which could then be broken down further as well as needed.

Once you get it installed, consider putting together some simple procedures and instructions, including how you'd like it used, how you want us to post docs and code, etc., and then request that the community start using it! The simpler the better. Perhaps kick it off by posting what's on Ogre's wiki page, but also including all tutorials and the guides for both major versions, then the community can help add on to the existing documentation base. Also, a list of exactly what's implemented now in each version, both Bleeding and Bloody Mess, like spacegaier started for Bloody Mess in the Ogre Wiki (http://www.ogre3d.org/wiki/index.php/NxOgre_Features). However, I think as a community, we need to also list what the limits are of each piece of the implementation, as well as the stability of each feature, in both version, so new users can immediately make informed decisions about what version to use based on their needs, and seasoned users can know what they need to help work on or more completely test. This way Bleeding can eventually be phased out, and only a single stable version of NxOgre will exist. Once bloody mess becomes stable, and implements all of the features of the previous version, consider just referring to it as NxOgre, or the version number, instead of Bloody Mess, as I think this confuses newcomers into thinking that it is a "Mess",and thus not stable. It's also always been a challenge when going through the forums looking for code for different versions that is implemented differently. Perhaps also a place where you can list what you need help writting, and people can easily submit things like joints to take the burden of doing everything off of you. Then if code starts to get shared as people finish writing stuff, we'll all have a solid, stable repository to share.

There also needs to be a place to request documentation. For example, I know what Flour is, and what it does, by the short description posted on the wiki. But as I haven't been using NxOgre for 3 years, I don't know where in the life cycle of a game I should use it, what problems it can solve, it's compatibility, etc. Therefore, a piece of documentation needs to be written by someone in the community that can answer these questions. This is just one of many examples that the community needs to work together to solve. The seasoned users often neglect these things as they already have a solid understanding from years of use. However, new users are are getting frustrated and scared away by NxOgre as although it is easy to use, it is hard to find an implementation of what they want to use it for, or documentation on how it is done. A library, no matter how feature rich, doesn't have much use to a person if they don't know or understand how to use it to solve their problems. I believe you want to attract as much talent to NxOgre as possible, as this means that more people will be contributing and helping to make it more robust, and also working to help you make it a complete solution. Then down the line, you can consider requesting that if anyone's projects that use it are profitable, that they please consider making a donation to you to help with maintenance costs and keep it active. Then it just may pay the bills for you as well.

The only major challenge I see with this solution is making sure that some random spammer doesn't come in and start trying to destroy the system and the work everyone puts in, as has happened to some projects. A solid and consistent backup plan and having the more active community members help monitor can help solve this problem though.

Absolutely. I have found one minor-nuisance; is that each project has it's own separate wiki and forums. Which is a bit to much, so I've made NxOgre the main project, then Cake and Flour sub-projects, with the wiki and forum options off. I've had to then modify some of the code to place the forum and Wiki links at the top of the page, so it's globally accessible.

I also totally agree with Bleeding, it needs to be phased out as soon as possible. But you won't change my mind about "BloodyMess", it's just a release codename.

Absolutely. I have found one minor-nuisance; is that each project has it's own separate wiki and forums. Which is a bit to much, so I've made NxOgre the main project, then Cake and Flour sub-projects, with the wiki and forum options off. I've had to then modify some of the code to place the forum and Wiki links at the top of the page, so it's globally accessible.

I also totally agree with Bleeding, it needs to be phased out as soon as possible. But you won't change my mind about "BloodyMess", it's just a release codename.

Damn you're fast! ;o) Nice job! If I can't change your mind about BloodyMess, please just make sure the first doc that people read when they get to the site mentions just that, "that BloodyMess is the codename for the latest version of NxOgre and in no way refers to the stability." This way no ones gets confused.

BTW...one more request regarding stability...just my 2-cents, but when a new release is made, it should compile with no warnings or errors. This is also an increased sign of stability. The warnings that compile in Visual Studio are primarily just it being picky with the current high settings; however, they can be easily disabled in this case, by a little-known feature in VS, giving the appearance of a much higher level of stability -- plus, they are annoying to those of us who are cursed with perfectionisism. Here is code and info straight from Microsoft's docs on how to do this:

For warning numbers in the range of 4700-4999, those associated with code generation, the state of the warning in effect when the compiler encounters the open curly brace of a function will be in effect for the rest of the function. Using the warning pragma inside the function to change the state of a warning greater than 4699 will only take effect after the end of the function. The following example shows the correct placement of warning pragmas to disable, and then restore, a code-generation warning message:

// pragma_warning.cpp
// compile with: /W1
#pragma warning(disable:4700)
void Test() {
int x;
int y = x; // no C4700 here
#pragma warning(default:4700) // C4700 enabled after Test ends
}

int main() {
int x;
int y = x; // C4700
}

Note that within a function body, the last setting of the warning pragma will be in effect for the entire function.

The same block of #pragma warning(disable:4700) and #pragma warning(default:4700) to respectively disable/enable warnings at will can also be used right before and after header files, to ignore all warnings in a header you include from another source, or at the beginning and end of a source file to ignore all warnings of that type in a source file. Multiple can be stacked for various warnings as well.

Hope this is of assistance to you!

Yep, I was surprised how easy it was to set up. Setting test server up on the other hand was terrible. Linux is not easy to install, and not easy to work with. I ended up installing Ruby on my windows computer, and took a small fraction of the time to do so.

We do use pragmas in (see \BloodyMess\build\msvc\source\NxOgreConfiguration.h). I've filled out a few. Be my guest to add any more that you feel is necessary.

Absolutely. I have found one minor-nuisance; is that each project has it's own separate wiki and forums. Which is a bit to much, so I've made NxOgre the main project, then Cake and Flour sub-projects, with the wiki and forum options off. I've had to then modify some of the code to place the forum and Wiki links at the top of the page, so it's globally accessible.

Got to thinking about this again...any consideration on setting up each major component of NxOgre as a separate wiki and forums. Perhaps this would be overkill, but it might simplify finding relavent information faster when there isn't enough documentation immediately available. For example: Visual Debugger, Volumes / Trigger, Kinematic Actors, Static Geometry, Standard classes to use BloodyMess with Ogre, Terrain / Heightfields, Visual Remote Debugger support, ConvexMeshes and TriangleMeshes, Resource System, Fluids, Cloths, Rigid Bodies, Characters, Physical Particles, Data Streaming, Dynamic Mesh Cooking, etc. Just trying to throw out some things to think about during initial setup...

Yep, I was surprised how easy it was to set up. Setting test server up on the other hand was terrible. Linux is not easy to install, and not easy to work with. I ended up installing Ruby on my windows computer, and took a small fraction of the time to do so.

Good idea. Let us know when you need some external testers.

We do use pragmas in (see \BloodyMess\build\msvc\source\NxOgreConfiguration.h). I've filled out a few. Be my guest to add any more that you feel is necessary.

The only challenge is that if I fill them out on older code, the rest of the community won't be able to benefit from it on future releases.

I'm aiming it to be up on Saturday so everyone can play with, as for the pragmas that's true, but I was hinting at that you could do a patch.

I'm aiming it to be up on Saturday so everyone can play with, as for the pragmas that's true, but I was hinting at that you could do a patch.

Certainly. I'd be happy to help out. I'll take a look at trying to resolve those issues with the static build as well on Bloody Mess once you've got the latest version posted. Those are things that I can do to save you time, help the community, and also not get in the way of your direct development.

Very nice site!

gives me education
I do hope by this you mean official certified education, As opposed to it being more educational than working on a fully blown phys x wrapper. The reason i ask this is because my dad, By the time he did his degree (at the age of 20), He had already produced 2 fully fleged sdk's, And found that he only actually needed to work atall in the last year of university. He ended up getting a first class in computer science. Im sure you can do the same, Are you in your last year?

Cheers

Scratchy

I haven't been around much lately - my project using physx is sorta on the backburner until A) I get more time and B) Character controller stuff is fully in mess, but I wanted to comment on something I read re: Warnings.

I agree, warnings should be gone, but I feel they should be gone through clean, explicit code rather than simply disabling them on the compiler.

I agree, warnings should be gone, but I feel they should be gone through clean, explicit code rather than simply disabling them on the compiler.

1>n:\projects\nxogre.org\bloodymess\build\source\nxogrejoint.cpp(132) : warning C4800: 'NxOgre::Enums::JointSpringType' : forcing value to bool 'true' or 'false' (performance warning)
1>n:\projects\nxogre.org\bloodymess\build\source\nxogremswindowsfileresource.cpp(84) : warning C4996: 'fopen': This function or variable may be unsafe. Consider using fopen_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
1> s:\microsoft visual studio 9.0\vc\include\stdio.h(237) : see declaration of 'fopen'
1>n:\projects\nxogre.org\bloodymess\build\source\nxogremswindowsfileresource.cpp(87) : warning C4996: 'fopen': This function or variable may be unsafe. Consider using fopen_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
1> s:\microsoft visual studio 9.0\vc\include\stdio.h(237) : see declaration of 'fopen'
1>n:\projects\nxogre.org\bloodymess\build\source\nxogremswindowsfileresource.cpp(90) : warning C4996: 'fopen': This function or variable may be unsafe. Consider using fopen_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
1> s:\microsoft visual studio 9.0\vc\include\stdio.h(237) : see declaration of 'fopen'
1>n:\projects\nxogre.org\bloodymess\build\source\nxogremswindowsfileresource.cpp(93) : warning C4996: 'fopen': This function or variable may be unsafe. Consider using fopen_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
1> s:\microsoft visual studio 9.0\vc\include\stdio.h(237) : see declaration of 'fopen'
1>n:\projects\nxogre.org\bloodymess\build\source\nxogrerevolutejoint.cpp(122) : warning C4800: 'NX_BOOL' : forcing value to bool 'true' or 'false' (performance warning)
1>n:\projects\nxogre.org\bloodymess\build\source\nxogreshape.cpp(128) : warning C4800: 'unsigned int' : forcing value to bool 'true' or 'false' (performance warning)
1>n:\projects\nxogre.org\bloodymess\build\source\nxogreshape.cpp(130) : warning C4800: 'NX_BOOL' : forcing value to bool 'true' or 'false' (performance warning)

1>NxOgre - 0 error(s), 8 warning(s)

Eight warnings are nothing, and not all of them cannot be worked around.

Just making it more pretty now, and slowly converting it to the look and design of the old NxOgre.org. So far as you can see - it's going well.

I haven't been around much lately - my project using physx is sorta on the backburner until A) I get more time and B) Character controller stuff is fully in mess, but I wanted to comment on something I read re: Warnings.

I agree, warnings should be gone, but I feel they should be gone through clean, explicit code rather than simply disabling them on the compiler.

The ones relating to security should be pretty simple to fix without pragmas.

Just making it more pretty now, and slowly converting it to the look and design of the old NxOgre.org. So far as you can see - it's going well.

Looks like it's coming along well -- well done!