Rakkar's Blog - NxOgre reviewed

From [url=http://www.rakkar.org/blog/?p=183]http://www.rakkar.org/blog/?p=183:

In a nutshell, Rakkar (the chap who made that famous networking library) is making a game using PhysX, in which he reviewed NxOgre and turned it down. For bandwidth reasons I'll quote his reasons here.

1. Unclear memory management. While it’s clear that NxOgre handles most memory management for you, I don’t feel very comfortable putting new calls all over the place and trusting they were handled correctly. The architecture pretty much requires you do this.
2. Unique name convention for objects. This is similar to what Ogre does, and is one of the biggest annoyances about Ogre. I don’t want to name every damn class I want with a text string, especially not if I have to constantly work to make sure it’s unique.
3. Overhead. The documentation and samples for PhysX are just much more clear and straightforward, with better documentation, and it seems relatively easy to use. I don’t see the point of using NxOgre except to save me time, and without clear documentation it won’t save me much of anything. Plus, if I’m going to use a library it needs to be written at a higher quality level than what I saw or I’m not going to trust that it won’t crash or leak memory somewhere.


Now, I'm posting here because I'm hoping he'll notice and reply. But for his concerns I'll answer them all here and now.

1. Memory management is a big thing with NxOgre, all of you know that you have to go through factory methods to create something. There is no way you can do "new body(...)", the constructor is protected and will not compile. The only exception to this rule is shapes. Shapes is a tricky one because you can't add a shape after the body was created, with an added side effect that PhysX will crash with an NxActor without a shape attached on creation.

I could use the Gangsta-style approach and just use a string "cubeshape:1 2 1", process it and create and configure the required shape. That's a lot of processing overhead though.
The second way would to be replace it with a function or method createShape_cubeShape(1.0f), it's pretty enough as much as you can make it. It's also just instancing the class somewhere else, which the pointer stored anyway. And it's more code to process.

So, as you can see "new xxxShape" is the easiest and fastest implementation of it.

2. I agree names can get annoying, but if you use an empty string as a name. NxOgre will generate a name for you.

3. Now this is something I've made sure there is plenty of, and your the first person to complain against it. The ~40 tutorial projects that come with it show nearly all of the wrapped functions of NxOgre. Not only that when you open the related project, the code is staring you in the face, without wading through any Ogre or setup or shut down code. It's right there in 5-10 lines. Fully commented. Not only that, the tutorial numbers and content correspond to the PhysX lessons, which have their own 3-4 page documentation written by Ageia. Nearly all of that applied to NxOgre. Sure the code is different, it's easier to work with and 1/10th the size in lines, but it still applies. And not only that, we have a half written book, a little out of date, I must admit but it certainly helps for the newbie in us.



Anyway, I open up this post up for anyone to side with or against Rakkar. Please comment.

I really appreciate the work you've done with nxOgre. For (1), I kind of agreed with this when I first started using nxOgre, but I'm comfortable with it now and would disagree with Rakkar. (2) I have no problem with the naming convention in OGRE, in fact I appreciate the fact that I can use a string to retrieve an object if I so choose to.

(3) I have to completely disagree with, the "tutorials" are perfect, you open up a file and all you really see is the relevant code. It's absolutely the best thing I could want in documentation. And there's even enough stuff that you can still see how to implement PhysX directly if you like their samples better.

I don't think Rakkar spent enough time reviewing nxOgre. I for one am grateful for it.

I disagree with Rakkar on 1, 2, and 3, even though his famous for his networking library (RakNet) does not mean his superb in everything else. The first mistake he made is NxOgre is at version 0.4 and Release Candidate 3. The second mistake, his rant on Ogre itself.

In conclusion, his review is premature especially Ogre because he have no idea how powerful Ogre (the rendering engine) once you take a dip in the deep end. And NxOgre is still in development.

betajaen, don't let Rakkar phase you.

I had my own beef with him, but now I have a whole other reason to steer clear!! He is WAY off base with this!

Ya, I'm scratching my head over that one. I always thought RakNet was pretty spiffy, but when it came to physics, I was really impressed with NxOgre from first use.

i dont agree with any of the reasons.... but in some way i though the same about the reason 1, when i saw a *new* in the constructor it made me think, where is going to be deleted the pointer ?

usually you're responsible of all the memory you allocate, by calling the method this way, the *new* is in the client side, so.....
The second way would to be replace it with a function or method createShape_cubeShape(1.0f), it's pretty enough as much as you can make it. It's also just instancing the class somewhere else, which the pointer stored anyway. And it's more code to process.

yes, i agree, the more code you add the more you have to mantain, the more potential bugs you have.... etc, etc. But if you make the allocation/creation of shapes in the lib side you can for example change shape's constructors or anything else the client wont notice those changes and maybe this is one of the advices that a "design pattern guru" would give you.
That was my first though (hey, i'm not saying i'm a guru!! hehe).

But after reading the NxOgre's code i understand that the goal here was made it simple and i like it, and most important to me is that this library is orthogonal in design philosophy, so i can live with new in constructors, at least in NxOgre calls


Edit1:
betajaen, don't let Rakkar phase you.

@diehard, I say the same.

Edit2:
from Rakkar's blog:
Coding quality is above average relative to other freeware stuff, but still not up to the level I like to work with.

who is this guy ? come on.....

I did play around with the idea of making a few functions to handle the shapes a week back, so it would go:

mScene->createBody("myBody","cube.1m.mesh", CubeShape(1), 10.0f, Vector3(0,2,0));

Notice the UpperCase "C" on CubeShape, that it's creator function. However since the code in that function is basically:

cubeShape* CubeShape(float size, params<collisionmodel> p = params<collisionmodel>() {
return new cubeShape(size,p);
}

There isn't much point, the class is created somewhere else. It also adds confusion, with the name. C++ is case-sensitive but humans are not.

________________________________________________

Anyway whilst I'm here; I'll make a small announcement a week ago, Luis joined the 'Army, and has been helping out with the development with NxOgre. He came up with a brilliant idea of handling how shapes are stored and worked with - internally with NxOgre. It's a lot faster and uses a lot less casting (none).

This means now you can actually sub-class the shape class, and create your own shape and NxOgre will accept it with no questions asked.

I also took the idea to the extreme as well, and pretty much gutted the entire shape system, it's still a little mess now (only 5 of them work!) but this is the new syntax you'll see with all shapes in the new release of NxOgre.

new cubeShape(1);
new cubeShape(1,2,1);
new cubeShape(1,2,1,"group: myGroup, CCD: yes, CCD-delta: 2.34");
new sphereShape(0.5, "skin-width: -0.5f");
new capsuleShape(2,0.75, "offset: 0 3 0");
new convexShape("myConvex.mesh", "material: bouncy");


Obviously the numbers are the sizes of the shape, but the second part is the new "collision model params" class. All of the shapes (well the ones that work) accept them now. Giving a lot of new features into these shapes, that I should of written in a long time ago.

Most of these issues go away after you've had a little experience with NxOgre. I would agree with Rakkar on documentation, except for the fact that NxOgre is changing rapidly, and documentation would end up out of date fast (is there a public NxOgre wiki? That might be a good idea). Plus, a little source digging and forum searching fixes most problems.

NxOgre.org is the wiki, but I don't use it anymore. I will be moving the entire website to some Python/Turbogears combo when I have time, then start writing the documentation there.

When I have time, that is.

From my beginner level I can comment about the documentation. Not I share the opinion of Rakkar, I am leaving from zero in the world of Ogre and NxOgre. The documentation is very good, according to my opinion. First read the tutorials of Physx and then the corresponding of NxOgre... and I have not had any problem. Also the book written by betajaen, is very easy of reading, to understand and pleasant. On the other hand the help surrendered by the members in the forum is very important, I am very to pleasure with you.

Also any inconvenience with NxOgre you can solve directly with Physx

The complete book would be brilliant

I'm pretty new to the world of programming but I must say I've found it quite easy to pick up how NxOgre works, for me, the tutorials are by far the easiest way to understand exactly how things work and the book is written in such a way that it's so easy to remember whilst also being fun to read.
I personally think that Rakkar has based his opinion as though NxOgre and it's documentation is finished or is at least at a version 1 stage and I guess if that were the case his points would be perfectly valid but as NxOgre isn't at that stage, I think he's done you (betajaen and his helpers) a huge injustice.

I would also like to say betajaen, don't let Rakkar phase you.
Without the NxOgre team and this comunities help my game idea would still be just a dream.

Thank you to all of you

I share Rakker concern with regarding to memory management. I've not dug into NxOgre code enough to verify this, but most libraries are not written with exception safety in mind.

So I do prefer to handle the memory allocations/deallocations myself via smart pointers. At least I know it won't leak. And also I could delete them while loading different levels too (I don't know if it is already available feature to delete shapes)

If you are ever redesigning the architecture, it would be nice to have option to manage memory ourselves.

NxOgre used to have that system, storage bodies were expected to be handled by you and you created them via the new operator.

I just followed the Ogre model, store everything and handle it through factories.

I have to say Betajaen does a wonderful job on NxOgre, but in the same vein Rakkar's should be taken as criticsm, not to be ignored just like that as I am sure he has some valid points there. From one perspective, forgive him for being honest and straight as I am sure he doesn't simply make them up. As for me, there are a few improvements that can be made:-
1 - The first letter of class name should be upper class, and the rest lower case much like Ogre's.
2 - Some parameters are not being passed too efficiently (although it may not cause any imaginable performance drop) like:-
- if parameters are not changed eg read only, it should be passed as const String& var instead of String var.
- every parameter passed which has size > float/double should always be passed as reference, not value even though they are meant to be read-only.

I must say the above 2 are bothering me a little, although they are actually insignificant.

If I were you I would remove the NxOgre book/guide. It's incomplete and very out of date, and as such probably does more harm than good. Of course, the best option would be to update it.

With regards coding style, I only really have a few minor gripes - there's a fair amount of inefficient coding (passing by value, multiple if statements) which could be easily tidied up.

Anyway, keep going, it's wonderful how much effort you're putting into this.