betajaen
08-02-2007 20:06:28
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.
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.
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.